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

If you want to see how Result and URLSession interact, take a look at the internals of Alamofire. We use our own Result type to encapsulate the end result of the chain of events involved in making a request and processing a response. I’ve also used this Result to form the basis of two

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

> On May 2, 2017, at 6:35 AM, Vladimir.S via swift-evolution > wrote: > 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:

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

That's horrible news for anyone that uses generic higher-order functions. I think a proper solution to the generic problem should be in place before these breaking changes are made. > On May 2, 2017, at 1:35 PM, Vladimir.S wrote: > >> On 02.05.2017 8:17, Gor Gyolchanyan via

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

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(pass parameter: A, to closure: (A) -> B) -> B { closure(parameter) } func bar(one: Int,

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

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(pass parameter: A, to closure: (A) -> B) -> B { closure(parameter) } func bar(one: Int, two: Double, three: String) { print(“\(one) \(two)

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

I think that `Either` in the standard library with some means to provide generalized behavior for two-cased enums would be an amazing salve for this. Handling errors thrown in Playgrounds is one of the best examples, in my opinion, of why we need something like Either/Result in the standard

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

> On 2 May 2017, at 2:34 am, John McCall wrote: > >> >> On May 1, 2017, at 9:01 AM, Rod Brown via swift-evolution >> > wrote: >> I agree that the key problem with the current architecture that you're >> alluding

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

I deliberately avoid making any concrete suggestions, because you guys know a lot more about internals of Swift then me. I know how to use it (I know how to abuse it), but to really come up with the best way to compliment the error handling system to make the entire language fluidly work with

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

An alternative would be to make throwing error more widely available then just functions. What if property getters and setters could throw? That would mean that throwing properties could be passed as parameters that would require the `try` keyword. Stored properties could have a new type

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

> On May 1, 2017, at 9:01 AM, Rod Brown via swift-evolution > wrote: > > On 1 May 2017, at 8:16 pm, Gor Gyolchanyan > wrote: > >> Yeah, you’re absolutely right. the “value-or-nil” and >>

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

One motivation would be the fact that integrating throwing mechanism with this Result/Failable type would make error-friendly generics easier, especially the infamous `rethrows`. I think the concept of `rethrows` is a hack that is put there as a quick fix for overwhelming complaints about

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

> On 1 May 2017, at 8:16 pm, Gor Gyolchanyan wrote: > > Yeah, you’re absolutely right. the “value-or-nil” and > “value-or-reason-why-not-value” are two different things and the former is > used too liberally in place of the latter because of lack of support. > In that

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

The real beauty of this added mechanism is when you consider generics. It would be easy to write a generic function that operates on both throwing and non-throwing parameters, while preserving their throwing-ness. Think `rethrows` except not limited to immediate nonescaping calls. This part

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

I guess I failed to communicate my thoughts properly. My bad. You’re right, this is a completely orthogonal issue and you're right: this does take nothing more then a new enum type and syntax sugar on top of it. My first guess is to allow this: func foo() throws -> Int { guard

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

Yeah, you’re absolutely right. the “value-or-nil” and “value-or-reason-why-not-value” are two different things and the former is used too liberally in place of the latter because of lack of support. In that case, the Result type should not replace the error handling, but augment it. The error

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

On Mon, May 1, 2017 at 2:58 AM, Gor Gyolchanyan wrote: > I have read those documents before, but It’s worth re-reading them to see > if I missed something, but I’l still explain my motivation and seek > arguments against the postulated problem (rather then a specific

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

The problem I see with your argument is that the core reason why the optional cast failed is actually there: It was an optional value, and you forced it to unwrap without checking. This is a correct description of the error. If we plumbed our code with a tonne of errors saying “why this is

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

I have read those documents before, but It’s worth re-reading them to see if I missed something, but I’l still explain my motivation and seek arguments against the postulated problem (rather then a specific solution). (a) There are different types of error. Yes, there are different types of

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

On Sun, Apr 30, 2017 at 5:05 PM, Gor Gyolchanyan wrote: > > On May 1, 2017, at 12:10 AM, Xiaodi Wu wrote: > > You may wish to read the rationale behind the current error handling > design: > >

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

> On Apr 30, 2017, at 15:13, Gor Gyolchanyan wrote: > > So, what you’re saying is essentially equivalent to replacing Optional struct > with an Optional protocol with a default AnyOptional struct implementation, > right? I suppose something semantically identical could

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

So, what you’re saying is essentially equivalent to replacing Optional struct with an Optional protocol with a default AnyOptional struct implementation, right? Having the bulk of compiler magic moved to a protocol was one of my proposed solutions, but it still isn’t optimal due to associated

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

> On May 1, 2017, at 12:10 AM, Xiaodi Wu wrote: > > You may wish to read the rationale behind the current error handling design: > > https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst >

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

You may wish to read the rationale behind the current error handling design: https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst A Result type like you suggest has been considered and rejected in favor of the current design. Briefly, optionals and throwing errors are

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

> On Apr 30, 2017, at 9:29 PM, Robert Widmann wrote: > > >> On Apr 30, 2017, at 1:43 PM, Gor Gyolchanyan wrote: >> >> It doesn’t have to be a massive source-break, since this pitch is supposed >> to be a strict superset of what Optional and

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

> On Apr 30, 2017, at 1:43 PM, Gor Gyolchanyan wrote: > > It doesn’t have to be a massive source-break, since this pitch is supposed to > be a strict superset of what Optional and throwing is currently. > The only thing that I can think of at this moment that would break

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

I’d like to suggest a bit of redesigning the Optional type and throwing functions to provide a single powerful and flexible mechanism for dealing with unexpected situations. In short, The Optional would have an associated value of type Error added to its `none` case, which would describe the