They rethrow which is IMHO perfect for this. If the closure throws then the outer functions throws (e.g. requires try). This allows folks that have a need to throw if they want without forcing it on everyone.
On Thu, Apr 6, 2017 at 6:53 PM Ricardo Parada via swift-evolution < [email protected]> 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 < > [email protected]> wrote: > > On Apr 5, 2017, at 9:43 PM, Brent Royal-Gordon via swift-evolution < > [email protected]> wrote: > > On Apr 5, 2017, at 5:45 PM, Ben Cohen via swift-evolution < > [email protected]> 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: > https://bugs.swift.org/browse/SR-2979 > > *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: < > http://stackoverflow.com/questions/24116271/whats-the-cleanest-way-of-applying-map-to-a-dictionary-in-swift/24219069#24219069 > > > > 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
