[swift-evolution] [Pitch] Revamp Optional and Throws

[Vladimir.S]

On 02.05.2017 8:17, Gor Gyolchanyan via swift-evolution wrote:
> One major thing to keep in mind is how exactly will it behave in generic contexts.
> As a similar example, if you can do this:
> 
> func foo<A, B>(pass parameter: A, to closure: (A) -> B) -> B {
> closure(parameter)
> }
> 
> func bar(one: Int, two: Double, three: String) {
> print(“\(one) \(two) \(three)")
> }
> 
> foo(pass: (1, 2.0, “3”), to: bar)
> 

Sorry for the offtopic in this thread, but could someone clarify the destiny of 
SE-0110 
(https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md) 
which (when implemented) will disallow this code?
Will SE-0110 be included in Swift 4.0 at all?

Gor, also please note that SE-0110 should disallow sending of Void (i.e. () ) to the 
function that is defined as function without parameters, i.e. this should be an error:
func foo() {..}
foo(())

> This used to work without generics, but If I’m not mistaken, a proposal was accepted 
> to disallow passing tuples and the only argument of a multi-argument function, 
> leaving this use case kinda magical.
> This is an enormously useful feature for generic programming (especially with the 
> lack of variadic generic types), because this allows us to define higher-order 
> functions that operate on any type of function, regardless of their arity.
> 
> However we resolve the error issue, it has to behave in a similar way, so that 
> throwing and non-throwing functions can be dealt with in a uniform way in a generic 
> context without loss of information or security guarantees.
> 
>> On May 2, 2017, at 12:48 AM, Rod Brown <rodney.brown6 at icloud.com 
>> <mailto:rodney.brown6 at icloud.com>> wrote:
>>
>>
>>> On 2 May 2017, at 2:34 am, John McCall <rjmccall at apple.com 
>>> <mailto:rjmccall at apple.com>> wrote:
>>>
>>>>
>>>> On May 1, 2017, at 9:01 AM, Rod Brown via swift-evolution 
>>>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> I agree that the key problem with the current architecture that you're alluding 
>>>> to is it can't be easily/stored and transferred./Swift errors are great for live 
>>>> action but holding and passing after the throwing event is problematic, and this 
>>>> is an elegant solution. The storage issue is when holding it as a property, and 
>>>> the transferring issue is when passing it to a closure as a results of an 
>>>> asynchronous operation etc. These are both definitely cases where storage of the 
>>>> type-or-error makes perfect sense.
>>>>
>>>> I think the key problem getting this accepted by the Swift Team will be that it 
>>>> doesn't currently have any specific use in the standard library. As a low level 
>>>> set of types, errors are generated by the lower levels but rarely stored, so the 
>>>> Standard library doesn't need the storage. Generally the only place we have to do 
>>>> that is in end user code. And currently the standard library doesn't have to 
>>>> support asynchronous operations natively, so there's nothing inside the kit that 
>>>> would require it to do completion handlers with errors.
>>>
>>> We've definitely considered including a Result type, but our sense was that in an 
>>> ideal world almost no code would be using it.  It's hard to imagine an ordinary 
>>> API that ought to be returning a Result rather than throwing, and once you've 
>>> defined that away, the major remaining use case is just to shift computation 
>>> around, like with a completion handler.  That explicit computation-shifting 
>>> pattern is something we're hoping to largely define away with something like C#'s 
>>> async/await, which would leave Result as mostly just an implementation detail of 
>>> such APIs.  We didn't want to spend a great deal of time designing a type that 
>>> would end up being so marginal, especially if the changing role would lead us into 
>>> different directions on the design itself.  We also didn't want to design a type 
>>> that would become an obstacle to potential future language changes like, say, 
>>> typed throws.
>>>
>>> The downside, of course, is that as long as we lack that async/await design, 
>>> computation-shifting isn't real great.
>>>
>>> John.
>>
>> This makes sense and is sensible. I’m curious how such an API would play with the 
>> existing NSURLSession completion handlers and the like, but I’m sure the community 
>> can design something appropriate.
>>
>> I think the only remaining case is simply storing a result-or-error for later 
>> handling, storage to disk, etc. I agree with your contention that the vast majority 
>> of the use case for this type is for computation shifting. I think it would and 
>> should be rare that we would want to “store” as a variable the “result-or-error” 
>> type. Errors should be handled at runtime in the vast majority of cases, presented 
>> to the user or otherwise handled, and then moved on from, with the reason no longer 
>> being relevant.
>>
>> As you say, in the meantime, it does leave computation-shifting a bit ad-hoc and 
>> convoluted, but I think the community has standardized on the Result temporary 
>> solution.
>>
>>>
>>>>
>>>> This would therefore be an element in the standard library purely so we don't 
>>>> have 50,000 different libraries with 50,000 different result types. I'd love to 
>>>> see this standardised so frameworks were more compatible. I'm just not sure 
>>>> whether the Core Team would see it as pressing to try and officiate a certain 
>>>> type that they themselves don't use.
>>
> 
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>