[swift-evolution] Adding Result to the Standard Library

Alex Lynch lynch.sft at gmail.com
Fri Nov 3 15:42:49 CDT 2017 

Where are the guiding documents for swift's concurrency support? I have an
unrelated idea for the language that I think would be a sizable win for
concurrency. (I won't cross post it here.)

RE Error syntax:
Syntactic sugar that makes it easier to ignore errors is a miss-step, I
think. Errors differ from optionals in how you handle the un-happy path.

With optionals: if the data isn't there you either O1) abort, or O2) follow
an alternative, acceptable path.
With errors: if the data isn't there you either E1) log-and-abort or E2)
present the error, either directly or via propagation.

That is to say – with errors the programmer has a greater responsibly to
honor the _content_ of the error, not just its presence.
To merely ignore the error (which is possible to do with the `try?` syntax,
is almost always an anti-pattern.

TL;DR. Error handling bares a greater responsibly than optional handling.
Responsible code is safer code.

I support the introduction of a `Result` type into the language (perhaps as
a core-lib like Dispatch), because it follows the principle of
responsibility.

RE Async syntax:
In like manner, I don't think it's a good idea to make the _call site_ of
asynchronous functions the same as the call site of synchronous functions.
If this were the case it would be very easy to confuse asynchronous
functions as synchronous and accidentally make your own function
asynchronous.

If there is any change to the language to add syntactic wrappers around
async methods, I think they should be lexically demarcated just like
throwing functions are. For example:

```
try someThrowingFunction()

async someAsyncFunction() // the natural call signature here would have
been someAsyncFunction(callback: {} )
```

Just like `try` is not for the compiler, but is a flag for the programmer
to pay attention, so – I think – there should be a similar flag that causes
the programmer to pay attention to async functions.

EPILOG :
But the above example actually takes us directly into the topic of
promises/futures. (What is _actually_ returned if we call an asynchronous
function with synchronous syntax?)
I have lot of thoughts on promises, safely-implemented async functions, and
the general practice of concurrent programming in swift. But maybe this
isn't the best thread for that broader discussion. ???

Thoughts?


On Fri, Nov 3, 2017 at 12:16 PM, Benjamin G via swift-evolution <
swift-evolution at swift.org> wrote:

> 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
>>
>>
>>
>
> _______________________________________________
> 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/25e37514/attachment.html>

More information about the swift-evolution mailing list