Thanks Shawn. I understand that part. I asked mostly because Nate mentioned that we cannot have a default closure because it would force the use of try even when the default closure does not throw. I do t know if that is a current bug or feature to allow changing the default in the future to a closure that throws:
>>> https://bugs.swift.org/browse/SR-2979 Thanks. > On Apr 6, 2017, at 10:12 PM, Shawn Erickson <shaw...@gmail.com> wrote: > > 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 >> <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: 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 >>>> 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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
