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

[Brent Royal-Gordon]

> On Apr 6, 2017, at 9:51 AM, Nate Cook <nate at natecook.com> wrote:
> 
> 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 <https://bugs.swift.org/browse/SR-2979>

Ugh. If that's the case, I'd probably provide a merge-handler-argument-less version instead of using a default argument. But I would have the first argument of both be unlabeled.

Actually, if we're going to do that, maybe the non-merge-handling version should be failable. That's the one semantic a `resolveConflict` method can't provide, and of course trapping on error is still just one force-unwrap away if that's what you want.

So that would give us:

	init?<S: Sequence>(_ keysAndValues: S)
		where S.Iterator.Element == (key: Key, value: Value)

	init<S: Sequence>(_ keysAndValues: S, correctingConflictsBy resolveConflict: (Value, Value) throws -> Value) rethrows
		where S.Iterator.Element == (key: Key, value: Value)

I think that pretty much covers everything you could possibly want to do about a conflict.

(I'd do a similar thing to `merged`, and perhaps have `merge` return a Bool, if you don't give them `resolveConflict` functions.)

-- 
Brent Royal-Gordon
Architechies

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