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

2017-04-30 Thread Gor Gyolchanyan via swift-evolution
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 re

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

2017-04-30 Thread Robert Widmann via swift-evolution
This "revamp" is isomorphic to adding a Sum type to stdlib and plumbing error handling syntax through. I'd much rather see that than the massive source-break this would entail. ~Robert Widmann 2017/04/30 13:11、Gor Gyolchanyan via swift-evolution のメッセージ: > I’d like to suggest a bit of redesi

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

2017-04-30 Thread Gor Gyolchanyan via swift-evolution
Well, the whole point was to make error handling syntax and semantics less magical and more generic-friendly, so you’re right, it is essentially a new sum type with error handling syntax on top of it. Except, adding it alongside optional would introduce accidental complexity to swift’s “unexpect

Re: [swift-evolution] [Draft] Package Manager Revised Dependency Resolution

2017-04-30 Thread David Hart via swift-evolution
Hi Rick, Thanks for taking the time to reply. I discussed the same argument with Ankit Aggarwal, and here are my counter-arguments: It seems to me like the survey should take into account the developer population using each tool. If we are doing such a survey to see what tool a programmer comi

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

2017-04-30 Thread Robert Widmann via swift-evolution
> 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 is this > syntax: > >

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

2017-04-30 Thread Gor Gyolchanyan via swift-evolution
> 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 throwing is currently. >> The only thing that I can

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

2017-04-30 Thread Xiaodi Wu via swift-evolution
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 distin

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

2017-04-30 Thread Gor Gyolchanyan via swift-evolution
> 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 > > > A

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

2017-04-30 Thread Gor Gyolchanyan via swift-evolution
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 ty

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

2017-04-30 Thread David Sweeris via swift-evolution
> 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 be implemented that way,

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

2017-04-30 Thread Xiaodi Wu via swift-evolution
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: > > https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst > > A Result type like you s

Re: [swift-evolution] [Draft] Package Manager Revised Dependency Resolution

2017-04-30 Thread Jon Shier via swift-evolution
`install` only sounds like it should install things in the system if that’s the only type of manager you’ve ever used. If I’ve only ever used brew, of course I’ll assume that every other thing that calls itself a package manager will operate similarly. Thankfully, people learn quickly an

Re: [swift-evolution] [Draft] Package Manager Revised Dependency Resolution

2017-04-30 Thread David Hart via swift-evolution
> On 1 May 2017, at 00:46, Jon Shier wrote: > > `install` only sounds like it should install things in the system if > that’s the only type of manager you’ve ever used. If I’ve only ever used > brew, of course I’ll assume that every other thing that calls itself a > package manager will