Closed acutmore closed 4 months ago
I'll also throw out zipKeyed
.
We discussed this today in Bloomberg's pre-plenary-prep and a few people were +1 on @bakkot's zipKeyed
. As the language's vocabulary already includes Object.keys
, Reflect.ownKeys
.
This thought only came to me during the last presentation when the proposal was about to get to stage 2.7 - while this is a little late at least we're not at stage 3 yet so might still be some wriggle room.
I am one of the champions for https://github.com/tc39/proposal-await-dictionary, which has some API similarities.
At a type level:
If there is
Iterator.zipToObject
it may be natural to mirror this for the "await dictionary" proposal. Leading to:This other proposal doesn't have to follow the naming style, but it feels advantageous if they could match. So I am wondering, with this other wrapper type in mind do we still want to go with
toObject
or maybe an alternative would be preferred?Some potential downsides with
toObject
: arrays are also objects, and the input is also expected to be an object. So the mapping isn't turning something into an object. It's turning the object inside out:Obj<Box<T>> -> Box<Obj<T>>
.Some starter suggestions:
Iterator.zipNamed
,Promise.allNamed
Iterator.zipDictionary
,Promise.allDictionary
Iterator.zipFromObject
,Promise.allFromObject