[swift-evolution] Adding Result to the Standard Library

[Benjamin G]

Except | is commutative, so you would except Int | Error to be equivalent
to Error | Int, which isn't the semantic of the Result type.


On Fri, Nov 3, 2017 at 4:04 PM, Elia Cereda <eliacereda at gmail.com> wrote:

> I'd say that this syntax would be even more coherent with protocol
> composition, given that x is effectively an Int *or* an Error:
>
> var x: Int | Error
>
>
> But aside from the specific syntax, I'm pretty sure it isn't the first
> time this request comes up and there were good reasons for rejecting it.
>
> Elia Cereda
>
> Il giorno 03 nov 2017, alle ore 13:10, Benjamin G via swift-evolution <
> swift-evolution at swift.org> ha scritto:
>
> Actually i'd even prefer :
> var x: Int ?? Error
>
> the spaces makes it more readable, it looks like what you'd do with the ??
> operator already, and it seems coherent with the syntax for protocol
> composition.
>
>
>
> On Fri, Nov 3, 2017 at 12:12 PM, Benjamin G <benjamin.garrigues at gmail.com>
> wrote:
>
>> Just an idea for the type declaration :
>>
>> Why not use the same ? as Optional, but with the type of the error behind
>> :
>>
>> Such as
>>
>> var x: Int?Error
>>
>> Optional Int (Int?) would be seen a special case of Result where the
>> error type is nil.
>>
>> The advantage of this syntax is that it would let us specify the type of
>> the error if we want it.
>>
>>
>> On Fri, Nov 3, 2017 at 11:45 AM, Nick Keets via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>> Right, to me there is not a lot of value in adding Result as it exists
>>> in AlamoFire. We will (eventually) use the Swift Package Manager for things
>>> like this. The value would be in integrating it like Optionals. e.g. (using
>>> a strawman symbol)
>>>
>>>     var x: Int‽ = 5
>>>     var y: Int‽ = anErrorValue
>>>
>>>     func foo() -> Int‽ { ... }
>>>
>>>     if let x = foo() {
>>>         // x is Int
>>>     } else {
>>>         // somehow access the error
>>>     }
>>>
>>>     guard let x = foo() else {
>>>         // Again somehow access the error
>>>     }
>>>
>>>     func bar() throws -> String { ... }
>>>     let x = try‽ bar()   // x is String‽
>>>     let y = x!  // y is String
>>>
>>>     // Possibly even make it throw? (just using a random symbol again)
>>>     let z = try x¡
>>>
>>>
>>> On Fri, Nov 3, 2017 at 2:02 AM, Xiaodi Wu via swift-evolution <
>>> swift-evolution at swift.org> wrote:
>>>
>>>> This is clearly a fine addition to the standard library; even Swift's
>>>> Error Handling Rationale (https://github.com/apple/swif
>>>> t/blob/master/docs/ErrorHandlingRationale.rst) mentions such an
>>>> addition
>>>>
>>>> What separates standard library types from other types is that they
>>>> have language level support, and the wrapping and unwrapping syntax here
>>>> could definitely benefit from it (`.unwrap()`--which should be
>>>> `.unwrapped()` incidentally--is so much less elegant in comparison to `?`
>>>> and `!` for optionals (not that `Result` should use the exact such syntax
>>>> for a distinct operation)). It would be a shame to transpose a third-party
>>>> `Result` to the standard library without considering if any such tweaks
>>>> would substantially improve ergonomics, interconversion with Optional and
>>>> throws, etc.
>>>>
>>>>
>>>> On Thu, Nov 2, 2017 at 1:08 PM, Jon Shier via swift-evolution <
>>>> swift-evolution at swift.org> wrote:
>>>>
>>>>> Swift-Evolution:
>>>>> I’ve written a first draft of a proposal to add Result<T> to the
>>>>> standard library by directly porting the Result<T> type used in Alamofire
>>>>> to the standard library. I’d be happy to implement it (type and tests for
>>>>> free!) if someone could point me to the right place to do so. I’m not
>>>>> including it directly in this email, since it includes the full
>>>>> implementation and is therefore quite long. (Discourse, please!)
>>>>>
>>>>> https://github.com/jshier/swift-evolution/blob/master/propos
>>>>> als/0187-add-result-to-the-standard-library.md
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Jon Shier
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> 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
>>>>
>>>>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> 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/20171103/855711ad/attachment.html>