[swift-evolution] Adding Result to the Standard Library

[Hooman Mehr]

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> 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> 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
> 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/0ee825be/attachment.html>