tc39 / proposal-joint-iteration

a TC39 proposal to synchronise the advancement of multiple iterators
https://tc39.es/proposal-joint-iteration
70 stars 2 forks source link

Records and tuples #29

Closed pennane closed 2 months ago

pennane commented 2 months ago

Hi,

I was wondering whether the Record and Tuple proposal should be considered alongside this proposal? I believe it makes sense, given how many languages that support tuples also have the zip methods utilize them. (as far as I understand)

I like to envision a future for JavaScript with real tuples and records. If these two proposals are to coexist, I think it's fair to consider how they should behave together.

As I see it, there are currently Iterator.zip and Iterator.zipKeyed, which I find potentially conflicting if we were to introduce Tuple and Record counterparts in the future.

If the method names were changed to Iterator.zipToArrays andIterator.zipToObjects, as I understand they were before, it would be natural to also add the Iterator.zipToTuples and Iterator.zipToRecords counterparts when the time comes.

It could also make sense to leave zipToArrays as the conceptual default, and keep its name as Iterator.zip whilst keeping the others in the zipToTypes format, but in the long run, I see that being counterproductive.

bakkot commented 2 months ago

Even in a world with tuples, arrays will continue to be the default: that's already entrenched in things like Map.prototype.entries, Object.groupBy, JSON.parse, etc. It's would be fine to potentially add a zipImmutable or something, but the default and shortest name should be the array-producing thing.

pennane commented 2 months ago

I see now that you are right. Moreover zipImmutable and zipKeysImmutable are not as horrible as I thought they'd be before actually writing them down.

I have a grudge with js arrays, but as much I'd like there isn't really a way around it.

Thanks for a quick answer. I'll close this as its not really of futher priority.