-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
SeqMap.keys is Seq [ci: last-only] #10766
base: 2.13.x
Are you sure you want to change the base?
Conversation
I think either Doing something in between can probably avoid some surprises but not really prevent bugs. |
Not sure if lrytz agreed to undeprecate, so I pushed it as a separate commit, unsquashed. Sorry, Jenkins. To be clear, this PR was motivated by Ichoran's endorsement on the ticket, that even if
I can report that I do not feel wiser. |
I see the point that returning a Seq doesn't hurt and can prevent surprises. But if we don't actually guarantee anything then the value is very limited, surprises when using I think either |
This is only for SeqMaps that don't yet override. It could be restricted further to SeqMap1..4, to be more conservative. Then we can sort whether it's useful API etc under SIP-51. Otherwise, I'll have to at-notify Ichoran. |
67027de
to
bff3d35
Compare
it's not clear what the API intends:
|
Fixes scala/bug#12991
Ensure that
keys
of aSeqMap
is aSeq
.That satisfies the unwritten expectation that
keys
is ordered and mutually comparable.