[swift-evolution] Dictionary Enhancements
ben_cohen at apple.com
Thu Feb 16 18:26:57 CST 2017
Following up on Ted’s post regarding the opening up of stage 2, I’m starting a thread to discuss improvements to the Dictionary type.
Here is a list of commonly requested changes/enhancements to Dictionary, all of which would probably be appropriate to put together into a single evolution proposal:
init from/merge in a Sequence of Key/Value pairs (already raised as SE-100: https://github.com/apple/swift-evolution/blob/master/proposals/0100-add-sequence-based-init-and-merge-to-dictionary.md <https://github.com/apple/swift-evolution/blob/master/proposals/0100-add-sequence-based-init-and-merge-to-dictionary.md>).
make the Values view collection a MutableCollection (as in this PR: https://github.com/apple/swift-evolution/pull/555 <https://github.com/apple/swift-evolution/pull/555>).
Add a defaulting subscript get (e.g. counts[key, default: 0] += 1 or grouped(key, default:].append(value)).
Add a group by-like init to create a Dictionary<K,[V]> from a sequence of V and a closure (V)->K.
Add Dictionary.filter to return a Dictionary.
Add Dictionary.mapValues to return a Dictionary (can be more efficiently implemented than composition as the storage layout remains the same).
Add capacity property and reserveCapacity() method.
Have Dictionary.removeAtIndex return the Index of the next entry.
(once we have conditional conformance) Make dictionaries with Equatable values Equatable.
Please reply here with any comments or questions on the above list, or any additions you believe are important that are missing from it.
All methods added to the standard library increase complexity, so need a strong justification to reduce the risk of API sprawl. When requesting additions/modifications, please keep the following questions in mind:
Is the suggested addition a common operation that many would find useful? Can it be flexible enough to cover different needs?
Will it encourage good practice? Might it be misused or encourage anti-patterns?
Can the operation be composed simply from existing std lib features? Is that composition intuitive/readable?
Is writing the equivalent by hand hard to get right? Are there common correctness traps that this addition would help avoid?
Is writing the equivalent by hand hard to make efficient? Are there common performance traps that this addition would help avoid?
Might a native implementation be able to execute more efficiently, by accessing internals, than the equivalent implementation using public APIs?
As he has already written up SE-100 and another Dictionary proposal, Nate Cook has kindly offered to collate a new omnibus proposal for Dictionary, which will then get pitched here.
I will send another email about enhancements to Sequence/Collection algorithms shortly.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution