-
I said it was barely a new syntax. That means it is new syntax, but barely.
-
Sure, it's a consideration and I just considered that it's really easy.
And why are you being so angry at me for something I didn't say?
And also this is barely a new syntax. It's a comma and then another of a thing that is already there, not a brand new syntax, so your analogy is disingenuous
Barely a new syntax is brand new syntax, so the analogy is correct.
Can you not read? I'm suggesting an addition to an existing syntax, you're suggesting a whole new syntax. If I say we should add headlights to a car, it's like you asking why we haven't made a motorbike. FFS, can't believe I have to explain this.
"Can you not read?" violates our Code of Conduct, so be forewarned.
I'm saying that any modification to syntax whatsoever is "new syntax", whether it's a new construct or a change to existing syntax.
In your analogy, literally any hardware change is "new syntax".
I disagree. I rarely if ever have to iterate over key-value pairs of objects in modern JS. When something is a keyed collection with a dynamic number of entries, where a need for iteration might arise, it's a Map not an object. The syntax for iterating Maps is just fine and straightforward.
So because you don't do it, it's not common? That doesn't make sense. Who said it had to be a dynamic collection? Or even an plain object at all, like an array. Because if you use forEach, you can't break or continue and return just does what continue does. If you want an early return or a break you can't do that without some wacky stuff.
There's a difference between modifying some syntax by adding a small feature and adding entirely new syntax.
@coolCucumber-cat - I understand that the addition of this new syntax is somewhat minor - just a comma. That is, indeed a pro for it and one of the things I already weighed in when I said I personally don't feel like it's worth adding this syntax.
But, don't feel like you have to convince me otherwise - I'm just a random person on the Internet. There's some active syntax proposals tc39 has that I don't think should go in, and other syntax proposals that I really want - I share my opinions on these proposals, but that's really all I can do.
I still don't know what you think the downsides are, other than the fact that there's a syntax change. It's just a comma. If you needed to break out of a forEach loop, how would you do it? And the fact that you no longer have to decide which loop you want to use or everyneed to worry about this is nice too and we wouldn't be here wasting more time. You're not even the one that has to implement it or use it so I'm not sure why you would even care.
Let me approach it this way.
The JavaScript language already has way too many ways to do a loop, on of which (for each) isn't even syntactic. You also have the c-style for loop with the loop variable, and for in, and for of. While this syntax change you're proposing is "just a comma", it's also "yet another way to do a loop", it just happens to be living inside the for of loop's syntax. But, as you said, it doesn't use the iterator protocol so semantically it's very different from today's for of loop, even though you're able to fit the syntax into it.
If we're going to add a new way to loop (weather or not new syntax is involved), we better have a really, really good reason for it. Not liking to type out "Object.entries()" isn't strong enough of a reason for me personally.
When did I say it doesn't use the iterator protocol? It works the exact same way as Symbol.iterator, just with keys and values, not just values. I never said anything about the iterator protocol, other than when you mention it and I ask what the hell the it has to do with anything and that I never said anything about the iterator protocol. So once again, what the hell does this have to do with the iterator protocol?
for..of uses the iterator protocol by invoking a Symbol.iterator method on the iteratee. Objects don't generically have one.
I summarized this quote as "it doesn't use the iterator protocol". If it has nothing to do with the iterator protocol, I would assume that means it doesn't use it. Indeed, I don't know how it would use it.
For me the aspect of the traditional:
That I find disconcerting is that it is difficult to optimize. The for loop must iterate over the attributes of the object, but it extracts only the key. The statement inside the loop then uses the key to extract the value of the attribute. I wonder if it would be possible to consider:
for (const key : const value n object) {
...
}
which follows the initialization syntax of objects.
Sorry, I'm not familiar with who you are - are you an implementer who is noticing a difficult-to-optimize hot path? Or are you speculating?
If it's not a dynamic collection, I wouldn't need to loop over it, I'd know which keys it has - so that's uncommon.
If it's not a plain object but an array, there's already .entries(). (I personally never use .forEach for precisely the reason you mention).
And sorry for implying that what I do defines the common case. It doesn't. But I want to say that the problem (common or not) already has a straightforward solution in the language: the use of a Map instead of an object. I practice this solution, and have no troubles with it.
Exactly. Then why mention it? Just because I ask what that has to do with anything, doesn't mean it's not true. If you asked me why I breath air and I ask what that has to do with looping over an object, doesn't mean I don't breath.
Just because it's not dynamic, doesn't mean you don't need to know the keys. It could have optional keys, there might be loads of different variations. Just because it's not dynamic, doesn't mean it has to be completely static. And I can't always use a map. Using a map means I have to be the only one doing something with it, if I want to pass it around, everything else better also use maps.
Sorry if I misquoted you then.
But, is the assumption wrong? Does it use the iterator protocol? From the way you described the feature in the o.p. it sounds like the answer is no, instead it uses a new protocol that's similar to the iterator protocol, but also different.
So I believe my original conclusion still stands.