On Thu, Apr 6, 2017 at 6:53 PM Ricardo Parada via swift-evolution < swift-evolution@swift.org> wrote:
How important is it that the closure be allowed to throw when resolving
collisions? In my use cases merging dictionaries he resolving of the
collisions is always relatively simple. Shouldn’t they be as below maybe?
/// Creates a new dictionary using the key/value pairs in the given sequence, /// using a combining closure to determine the value for any duplicate keys. init<S: Sequence>(
merging keysAndValues: S,
resolvingCollisionsWith combine: (Value, Value) -> Value
) where S.Iterator.Element == Element
/// Merges the key/value pairs in the given sequence into the dictionary, /// using a combining closure to determine the value for any duplicate keys. mutating func merge<S: Sequence>(
_ other: S,
resolvingCollisionsWith combine: (Value, Value) -> Value
) where S.Iterator.Element == Element
/// Returns a new dictionary created by merging the key/value pairs in the /// given sequence into the dictionary, using a combining closure to determine /// the value for any duplicate keys. func merged<S: Sequence>(
with other: S,
resolvingCollisionsWith combine: (Value, Value) -> Value
) -> [Key: Value] where S.Iterator.Element == Element
On Apr 6, 2017, at 12:51 PM, Nate Cook via swift-evolution < > swift-evolution@swift.org> wrote:
On Apr 5, 2017, at 9:43 PM, Brent Royal-Gordon via swift-evolution < > swift-evolution@swift.org> wrote:
On Apr 5, 2017, at 5:45 PM, Ben Cohen via swift-evolution < > swift-evolution@swift.org> wrote:
• What is your evaluation of the proposal?
(As a meta issue, I'm not sure I like the grab-bag review style; I'm
finding this proposal a little bit difficult to navigate.)
*Sequence-based initializer and merging initializer*
Good idea, but I think these two are redundant with each other, and I
don't think "merging" is an accurate way to describe what the second one
does. (`merging` would suggest to me that it was combining several
dictionaries or lists, not combining conflicting elements.) I'd suggest a
single initializer along the lines of:
init<S: Sequence>(_ keysAndValues: S, correctingConflictsBy
resolveConflict: (Value, Value) throws -> Value = { fatalError("Duplicate
values \($0) and \($1)") }) rethrows
where S.Iterator.Element == (key: Key, value: Value)
Thanks for all your feedback, Brent! One note on this item in
particular—if you specify a default argument for a throws/rethrows closure,
you have to use "try" at the call site even if the default closure argument
doesn't throw. Modules currently don't promise that default closure
arguments don't throw, and a default argument could change from
non-throwing to throwing in a later version of a library.
There's a bug tracking the issue here:
[SR-2979] 'rethrows' function with non-throwing default requires 'try' · Issue #45569 · apple/swift · GitHub
*Merging methods*
Good idea, but I'm not a fan of the `mergingValues:` label. I would
suggest the same `correctingConflictsBy resolveConflict:` label I suggested
for the previous method—possibly including the default value. I also think
`merge(_:correctingConflictsBy:)`'s first parameter should be labeled
`with`, just as the `merged` variant is.
I wonder if we might also want a method that copies the Dictionary, but
with a single key added/removed/changed:
func withValue(_ value: Value?, forKey key: Key) -> [Key: Value]
*Key-based subscript with default value*
I like the functionality, but not way this proposal does it. I don't like
having the default value be a labeled parameter to the subscript, because
it isn't used to locate the value. However, I can't come up with a better
syntax without adding language features. What I'd like to do is make it
possible to assign through `??`:
frequencies[c] ?? 0 += 1
But that would require either that we support `inout` functions, or that
`??` become magic syntax instead of a standard library feature. The former
is not coming in Swift 4 and the latter is less than ideal.
Still, if we would rather have that syntax and we think we'll soon have
the language improvements needed to pull it off, I'd suggest rejecting this
portion of the proposal.
*Dictionary-specific map and filter*
I am +114 on this. I say that because I have received 114 upvotes on my
Stack Overflow answer explaining how to write a `Dictionary.map` method: <
What's the cleanest way of applying map() to a dictionary in Swift? - Stack Overflow
>
I agree with the decision not to pass keys to the closures in these
methods; that keeps them simple and focused, and ensures they stay parallel
with ordinary `map` and `filter`. I also agree with the decision to not
build in a form of `map` which allows key remapping; you can always do that
with the sequence-based initializer, which would let you add
conflict-handling logic more elegantly than a key-value `map` could.
*Visible dictionary capacity*
I doubt I'll ever use the `capacity` property, but I'm not opposed to it.
Adding a `reserveCapacity(_:)` method is a good idea.
*A grouped(by:) method for sequences*
Yes, please.
*Apply relevant changes to Set*
These make sense. (I considered suggesting the `filter` method be called
`intersection(where:)`, but on second thought, I don't think that conveys
the actual use cases for the method very well.)
I wonder if we might want to conform `Dictionary` to `SetAlgebra`. They
have compatible semantics, and I've occasionally wanted to use them in the
same places. On the other hand, some of the methods might form attractive
nuisances; perhaps I should just write a SetAlgebra-conforming view when I
want to do that.
*General notes*
If SE-0161 is accepted, we may want to support key path variants of some
of these APIs (like `grouped(by:)`, `map(_:)`, and `filter(_:)`). On the
other hand, we may want to defer that so we can consider that issue
holistically, including with existing Collection APIs.
• Is the problem being addressed significant enough to warrant a change to
Swift?
Yes. These are all common needs; when working with dictionaries, I find
myself writing `for` loops with `var`s far more often than I'd like.
• Does this proposal fit well with the feel and direction of Swift?
Yes, these are all pretty straightforward additions.
• If you have used other languages or libraries with a similar feature,
how do you feel that this proposal compares to those?
Ruby's `Hash` has many of these features and I appreciate them there;
`NSDictionary` does not and it suffers for it. Perl hashes have a
flattening behavior that tends to be amenable to editing them in various
ways, but that's not really suitable for Swift.
• How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?
Quick reading.
--
Brent Royal-Gordon
Architechies
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution