Alternative naming for `zipToObject`

[acutmore]

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:

Promise.all (Array<Promise<T>>) ->  Promise<Array<T>>

Iterator.zip(Array<Iterator<T>>) -> Iterator<Array<T>>

If there is Iterator.zipToObject it may be natural to mirror this for the "await dictionary" proposal. Leading to:

Iterator.zipToObject(Object<Iterator<T>>) -> Iterator<Object<T>>

Promise.allToObject (Object<Promise<T>>) ->  Promise<Object<T>>

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

[bakkot]

I'll also throw out zipKeyed.

[acutmore]

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.