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@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution