> On Apr 6, 2017, at 9:51 AM, Nate Cook <[email protected]> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
