Amend a typing decision?

[gwhitney]

By what I would consider a series of historical accidents, in TypeScript, if A is of type T[] and n is of type number then A[n] is of type number but A.at(n) is of type number|undefined. It's as though TypeScript thinks that "ooh, negative numbers are hard, you're much more likely to mess up your indexing with at." So as a result I end up with ugly type assertions or lots of or DummyTs all over my code in places where it's convenient to work with negative indices, such as when the elements are naturally indexed by $\mathbb Z_n$.

Any chance Civet could/would translate A.at(n) to (A.at(n) as T)? (Any reason that would be a really bad idea? I couldn't see one, which is why I posted.)

[edemaine]

I wonder if Civet is the right level to fix this. Fundamentally, it's a TS lib issue. So I wonder if it makes more sense to override the es2022 lib that introduced at using an NPM patch, and possibly TS's lib override support.

At a practical level, it's hard for Civet to fix this, because it would need to know the type of A and realize that it's deriving from this particular lib declaration... (not just Arrays, but things that extend it, etc.)

[gwhitney]

At a practical level, it's hard for Civet to fix this, because it would need to know the type of A and realize that it's deriving from this particular lib declaration... (not just Arrays, but things that extend it, etc.)

Fair enough. The path of least resistance for me is just to define an operator arr at i that's properly typed. Since I do this a lot, I'd like to make it a single character, which is my original motivation for #1034. (Unfortunately @ is taken ;-) but Unicode is big enough to find something comfortable.)

[gwhitney]

P.S. I am happy to close this discussion or have you do it but didn't think I should unilaterally even though it seems I can...