> On Nov 6, 2017, at 4:13 AM, Jon Shier <j...@jonshier.com> wrote: > > This consideration is further complicated by the possible addition of > typed throws in the future. However, the most commonly suggested > implementation fo typed throws keeps the ability for throws to be untyped. > Additionally, the feature usually allows multiple types to be thrown from a > single function. Result<T> can handle all of these scenarios automatically, > since it reduces all errors down to Error. A Result<T, E> however, would > either lose the ability to encapsulate any function with multiple error > types, or otherwise have to wrap those cases in something like AnyError, in > additional to having to do so in the untyped case.
As I mentioned up-thread, this proposal isn’t going to go anywhere without a proper discussion of typed throws. There are good reasons for two possible designs: 1. Never add typed throws. 2. Add the ability to specify a single type thrown (typically an enum, but could be a struct), which defaults to Error if unspecified. I don’t see any reason to add an arbitrary *list* of thrown types. Swift already has ways to specify alternatives (enums) and this would encourage exactly the behavior from APIs that we want to avoid. This choice between 1/2 needs to be decided before introducing result, because #1 means it should be Result<T>, and #2 means it should be Result<T,E>. If this is important to you, I’d suggest starting a dedicated discussion thread about the topic. -Chris
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
