Fix `.at`

It may be a more convenient method when it takes Object as indexable by keys rather than indexed numbers.

Why would that be convenient? The point of .at() is to be able to use negative and positive numbers interchangeably; for objects, there's no "wraparound" - just the key, or nothing, so obj[key] is more convenient than some kind of [obj.at](http://obj.at)(key) (setting aside that that would break with an object having a key of at.

1 Like

OK, I have seen the rationale.

I suddenly came up with an idea that we can create a new syntax like arr.[-1] to solve this problem. Is it reasonable to do so?

1 Like

Now that .at is stage 4 and done, finding another solution isn’t particularly reasonable.

For that specific idea, see https://github.com/tc39/proposal-array-last/issues/28

I understand, I meant to create a completely new proposal (I don’t have enough knowledge to write it by myself, though). Shall we start another topic then?

The way the proposal process works is you first define the problem you're trying to solve (in this case, negative indexing), then you explore different solutions until you settle on one and implement it. This whole problem-defining, exploring, and solving process roughly map to the different proposal stages.

The problem .at() was trying to solve was the fact that it's inconvenient to do negative indexing. They already explored different solutions, including a syntactic option for it, as @ljharb linked to. Ultimately, they decided that the best solution would be to provide a .at() function.

It would be silly to start a new proposal right after we got .at() out the door, that seeks to solve the exact same problem .at() was trying to solve. .at() is the intended solution for this problem. It was decided that they didn't want to pursue a syntactic solution.

Edit: Perhaps "syntax already being explored" was a bit of an overstatement. Just realized that issue was on a different proposal, not on the .at() proposal. Perhaps they explored it in .at() as well, but I haven't looked into their issues to find out.

I'd comment on proposal-array-last; I think that is the proposal for "a way to get at the last item in an array", now that the "relative indexing method" proposal is finished.

Wouldn't you LOVE if the engine told you you have an error so that you could fix it?

I have to agree with the sentiment that new APIs should leave the bad parts behind. Mimicking index treatment of .slice is not a benefit.

Keeping compatibility with existing semantics is mostly important, but I think most people here will agree leaving some (bad) parts behind would be more ideal.

1 Like

I would call it more of an ecosystem mishap that carried forward too far due to the sometimes-uncontrollable nature of human masses.

This is why politics are so sketchy. Imagine if in January all those people actually broke into U.S. congress. It could have happened, and it could have ended with dead politicians, and all of it sort of randomly at that. People "blamed" Trump although maybe he didn't actually order it.

To this same effect. I'm sure parts of the language have carried on because things were there, and people simply continued to use them. This happens a LOT. I see it all the time in code bases. People copy a pattern without thinking of a different solution, just to get things done.

I would highly consider the chance that JavaScript's mistakes can easily be attributed to this random human phenomenon.

How can it be improved? Perhaps by making a better consensus system. At the moment, there are a very few amount of people in TC39 that, in my opinion, are not valuing developer experience as highly as we could.

That's not flexible, and forces people into silent errors. This is better:

const index = 0.3 + 0.3 + 0.3 + 0.1 // 0.99999
[1, 2, 3].at(index) // error, makes the user *aware*
[1, 2, 3].at(Math.round(index)) // ok, as the *intent* shows.

JavaScript should make things easy, but it shouldn't make things too easy to the point it doesn't make sense.

Stage 4 proposals have been modified in the past.

Not for design-based reasons, and not when there’s delegates that don’t agree with the change. It’s not going to happen.

What if the processes were more community-oriented. One can wish.

This is hilarious, it's not at that's broken, it's the whole language :laughing:. Still, might be nice if in strict mode or something, these behaved more intuitively!

1 Like