GeezerVison

Do we actually want to make this optional? slice() makes sense because it's common to copy an entire array, I don't know if allowing forgotten arguments is worth supporting the idiom of peeking at the front.

If leaving it with no parameter defaults to 0 and is valid, why not? Typescript is supposed to pick up on runtime errors, which this is not one

This would be possible with optional parameter:

// some function that omitting parameter actually makes sense
function foo(index?: number) {
  // ...
  const item = bar.indexAt(index);
  // ...
}

But I'm not sure how many people would do that. I'm happy to revert the last commit but I wonder what others think.

Any function would work like that for that matter. I think if it’s supported it should be kept like this

Typescript is supposed to pick up on runtime errors, which this is not one

We have lots of precedent of not supporting everything under the sun just because it doesn't crash (e.g. #15122). If it's plausibly an error, we occasionally err on being restrictive.

Absolutely not. This situation is much different from the one above because that one doesn't make sense and has alternatives. This here has an alternative, which is passing an explicit 0, but when running .at() it would make sense for it to default to the first element in the array. This doesn't seem like another one of JS's quirks, but in fact very much intentional and should stay like this, unless a maintainer says otherwise

I can't find any discussion from TC39 that says this is intentional, though. Happy to see one if exists.

Sorry to complicate this merge late in the game, but I think we want at(index: number): T | undefined; - #45512 (comment)

WRT the idea of index?: number vs index: number I don't personally have a strong opinion either way, but if forced I think we should drop the ? and go with index: number because I think it matches the intention of at(0) which feels different to at(undefined)/at() because the omission doesn't really communicate the same thing

Two MS engineers prefer not to making it optional 👍

I'll add | undefined and the newly accepted Error Cause proposal tomorrow (unless anyone prefers to making it a separate PR).

I can't find any discussion from TC39 that says this is intentional, though. Happy to see one if exists.

I don't think there was explicit discussion, but certainly as a member of TC39 it is my view that at coerces undefined to 0 only because everything similar in the language works that way, not because we actually think people should pass undefined or omit the parameter. By analogy, you can also call it with '0', but that doesn't mean | '0' belongs in the signature.

As a user, if I ever saw at being called with undefined or without an argument, I'd assume that was a bug.

If ES2022 does not contain new syntax, should we skip ContainsES2022 flag (or set ContainsES2022 = ContainsES2021) to save the bitflag?

There are (notably class private fields), but just not here yet AFAIK.