[swift-evolution] Adding Result to the Standard Library

[Benjamin G]

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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171103/9ebbd14d/attachment.html>