-
Notifications
You must be signed in to change notification settings - Fork 61
Tuple.prototype.groupBy #275
Comments
The lists should be tuples, because they are "sublists" of the original tuple: I don't have an opinion regarding the external wrapper, but if we choose to produce an object it will be easy to convert it to a record because it only contains primitives: |
Well, since cc @jridgewell, if you have any opinion about this. |
That said, it would be perfectly reasonable for it to return a Record of Tuples in this case, instead of an object of Tuples. |
I don't think must, but I think this is the right choice. Whether it's a record or an object, doesn't really matter to me. |
Thinking some more: Returning an object has the benefit of supporting grouping by |
Why couldn’t you group by a symbol in a Record? |
Records don't allow symbol keys (because they cannot be sorted). |
Oof, right. In that case it should probably return an object. |
alternatively, |
It was suggested in tc39/proposal-array-grouping#30 (comment) that we look at So we could have:
|
I do like that. |
We intend to have an opened draft PR but will only consider a merge once https://github.com/tc39/proposal-array-grouping goes to stage 4 |
PR is now open and will be merged conditionally if there is a progression to Stage 4 on proposal-array-grouping |
Array.prototype.groupBy getting stage 3 made me think, I wonder what
Tuple.prototype.groupBy
would do 🤔The text was updated successfully, but these errors were encountered: