[swift-evolution] SE-165: Dictionary & Set Enhancements
zach at waldowski.me
Sat Apr 8 13:58:31 CDT 2017
zach at waldowski.me
On Wed, Apr 5, 2017, at 08:45 PM, Ben Cohen via swift-evolution wrote:
> • What is your evaluation of the proposal?
Overall, +1. Dictionary and in Set are in need of interaction
improvements. However, given the increased need for considering source
stability, I'm of the opinion adding new stuff to the stdlib should face
an appropriately high bar; so specific and nit-picky notes follow.
- The `init(_ keysAndValues: Sequence)` should be `init?(_:)`.
- The merging family does not feel completely in line with Swift
naming. Considering other closure-taking methods in the stdlib, I
feel like "by mergingValues" is a better fit, since "merg[ing]"
already comes up in the signature, netting you `Dictionary(merging:
listOfPairs, by: max)`.
- I'm not sure subscripts allow all this right now, but `default
defaultValue` seems like an appropriate candidate for being
`@autoclosure` and `throws`, and the subscript itself `rethrows`.
- I retract my concerns over the merging methods, but I still don't see
the API benefit of `mapValues`. This doesn't seem like it pulls its
weight besides an optimization. With SE-0154 and conditional
conformances, I feel like the same optimization could be possible with
`init(_ keysAndValues: Sequence)` and `lazy`. So -1 there.
- Source-breaking changes from `filter(_:)` overloads feel more
problematic than described in the proposal. Both behaviors (returning
Self and returning Array) are useful, and I don't want to lose easy
calling of one. The desired behavior can also be accomplished using
one of the initializers and `filter` or `lazy.filter`. -0.5 on that.
- As much as I want it personally, `grouped(by:)` feels like a weak
specialization of `init(merging:mergingValues:)`. Now, of course, that
would be better (for performance, readability, etc.) if `combine` were
`inout`. This parallels nicely with the subscript-with-default being a
mutating l-value. I don't remember how `reduce`-with-`inout` fell out
back in January, but this feels like it's in similar territory. I just
don't want to lock us into a collection of methods that are only
slightly only different enough to be frustrating when using them.
> • Is the problem being addressed significant enough to warrant a
> change to Swift?
For sure. Arrays and generalized collections are best-in-class; the
hashed collections are only slightly less so.
> • Does this proposal fit well with the feel and direction of Swift?
With some nits as noted above, yes.
> • If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
I, for one, don't feel like Dictionary needs to shoot much past the
capabilities of NSMutableDictionary, but should definitely at least
match it; this proposal gets us pretty close.
> • How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
Followed the proposal since inception. Uh, big user of dictionaries,
> More information about the Swift evolution process is available at
> Thank you,
> Ben Cohen
> Review Manager
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution