[swift-evolution] SE-165: Dictionary & Set Enhancements

[Zach Waldowski]

Responses inline.



Best,

  Zachary Waldowski

  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,
I suppose.


> 

> More information about the Swift evolution process is available at
> https://github.com/apple/swift-evolution/blob/master/process.md
> 

> Thank you,

> 

> Ben Cohen

> Review Manager

> 

> 

> _________________________________________________

> swift-evolution mailing list

> swift-evolution at swift.org

> https://lists.swift.org/mailman/listinfo/swift-evolution


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170408/f61e9971/attachment.html>