[swift-evolution] Adding Result to the Standard Library

[Hooman Mehr]

Oops, forgot to put the initializers that are the most useful:

    public init(_ expression: @autoclosure () throws -> T) {
        do { self = .value(try expression() ) }
        catch { self = .error(error) }
    }
    
    public init(_ closure: () throws -> T) {
        do { self = .value(try closure()) }
        catch { self = .error(error) }
    }


> On Nov 14, 2017, at 6:57 PM, Hooman Mehr via swift-evolution <swift-evolution at swift.org> wrote:
> 
> You can support all styles with enum as well. What don’t you do this:
> 
> public enum Result<T> {
>     
>     case value(T)
>     case error(Error)
>     
>     public init(_ value: T) { self = .value(value) }
>     public init(error: Error) { self = .error(error) }
> 
>     public func get() throws -> T {
>         switch self {
>         case let .value(value): return value
>         case let .error(error): throw error }
>     }
>     
>     public func map<U>(_ transform: (T) throws -> U) throws -> U { return try transform(get()) }
>     
>     public var value: T? {
>         switch self {
>         case let .value(value): return value
>         case .error: return nil }
>     }
>     
>     public var error: Error? {
>         switch self {
>         case .value: return nil
>         case let .error(error): return error }
>     }
> }
> 
> 
>> On Nov 14, 2017, at 3:40 PM, Guillaume Lessard via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> I’m late to this particular party, but having just caught up with the thread I’m surprised that no one substantially addressed the stylistic duality that a `public enum Result` would bring.
>> 
>> In short, I’d rather Result be a struct than an enum.
>> 
>> I too implemented a Result, for obvious reasons. I was, however, unsatisfied that it added another interface for error handling, namely switching over the enum — it’s not really better, not really worse, but now there are more error handling patterns to look for in your code.
>> 
>> My solution was to simply switch to a `struct Result`, where the enum is private. The only way to get the value out is via a throwing method. See <https://gist.github.com/glessard/48f4c1305ac20b1b99c1bbdc2fb6290c <https://gist.github.com/glessard/48f4c1305ac20b1b99c1bbdc2fb6290c>> for a no-frills implementation.
>> 
>> This has all the advantages of the Result enum — it’s easily used in asynchronous situations and can implement the desired functional/monadic niceties, but without exposing an unnecessary alternate interface to Swift’s native error handling.
>> 
>> Cheers,
>> Guillaume Lessard
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171114/8dc2cb5a/attachment.html>