-
Notifications
You must be signed in to change notification settings - Fork 62
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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: