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