[swift-evolution] [proposal] Either in the Swift Standard Library

Tue Jan 26 16:24:11 CST 2016

Okay, we’ll stop quibbling about the name (I’ll try to use “sum” from here on out), I want to focus on the first part of this because I think it’s great.  There are definitely limitations to extensions like that, but I don’t think they should impede the inclusion of the data type itself.  For one, if we’re going to focus on strong typing, then it not being usable seems a feature not a bug.  Can you think of any more in with respect to the fully-generic form?

> On Jan 26, 2016, at 5:11 PM, Kevin Ballard <kevin at sb.org> wrote:
> 
> I don't want to replace throws. I love typed errors in Rust, but I recognize that Swift's integration with Obj-C (and hence NSError) means that if we replaced throws with a Result, we'd almost always end up with Result<T,ErrorType> instead of a strongly-typed Result<T,E>. I think the stdlib should have a Result type (whether it's Result<T> or Result<T,E> I'm not sure yet, I like the latter but there's limitations in Swift right now that prevent that from being used to represent Result<T,ErrorType> very well, e.g. any extension where E: ErrorType won't be usable on Result<T,ErrorType>), but I'm not really pushing for its inclusion right now because of those limitations. The use of a Result type in the stdlib would not be to replace current usage of throws but instead to be used in cases where throws can't work (e.g. deferred computations, completion blocks, etc). But I am talking about Result because it's the closest thing to the type you're pushing for that I would actually be comfortable having in the stdlib.
>  
> When you say this type "just kept showing up", all of the motivating examples in your proposal are in fact motivating examples for a Result type. I'm guessing most of the specific concrete examples found in your own code are the same. And, assuming you have any non-Result examples at all in your code, I suspect that the remaining examples would be better served by defining a separate more specific type. And if you have some truly generic functional code that wants to return a truly generic 2-ary sum, you still probably want a new enum anyway since you probably don't want left-biasing there (in my experience, a left-biased generic enum usually only makes sense when it's filling the role of a Result).
>  
> -Kevin Ballard
>  
> On Tue, Jan 26, 2016, at 02:01 PM, Developer wrote:
>> I’m sorry to have to stand so firmly against this, I really do like Result and in any other context I’d probably be with you pushing for its inclusion, but I wrote this proposal in response to the last time this was shot down internally.  I want to have my cake and make a Result of it to, and I can’t do that if I spend the entire proposal process pushing to secretly replace throws just because it’s convenient.  I drew this up because we had this thing in our frameworks that just kept showing up everywhere.  It turns out, we weren’t the only ones and that meant we had cause to push for inclusion.  If I come out guns-a-blazing with the typed throws crowd I don’t think I would get anywhere nearly as fast as pushing for the inclusion of a sum.
>>  
>>> On Jan 26, 2016, at 4:55 PM, Kevin Ballard <kevin at sb.org <mailto:kevin at sb.org>> wrote:
>>>  
>>> By my count, this is the third time I've said this: I don't want genericity of type. The Result type is only useful because it carries the specific meaning of having one "success" variant and one "failure" variant. It may look structurally identical to a left-biased Either type, but the specific naming here is very important. By trying for genericity, you're losing the specific meaning of the Result type and thus defeating the entire point of having a Result type.
>>>  
>>> -Kevin Ballard
>>>  
>>> On Tue, Jan 26, 2016, at 01:50 PM, Developer wrote:
>>>> Ah, so that’s what this has been.  When I say “Either” you immediately jump to “Haskell’s Either” when what I really mean is the structure forming the Either type.  Because I get the feeling you and Chris are coming from this from two different directions I’ve tried to be generic in my speech.  To me, both implementations are the same, one just happens to have a more immediately scintillating naming scheme.  By my count, this is the third time I’ve said this:
>>>>  
>>>> I am open to name changes, but we must preserve the genericity of the type.  
>>>>  
>>>> You haven’t yet convinced me of the latter half of that point.  Perhaps we should start again: How does Result, and the semantics is carries with it, maintain the genericity of the type over, say, something called Choice or XOR?  Down the road, when Swift decides to adopt a more generic approach or attempts to abstract over this kind of type, I’d like to say we were forward-thinking enough to have anticipated this rather than have to deal with un-Resultifying a datatype that should have been generic to start with.
>>>>  
>>>>> On Jan 26, 2016, at 4:40 PM, Kevin Ballard <kevin at sb.org <mailto:kevin at sb.org>> wrote:
>>>>>  
>>>>> You've mentioned Rust many times, but I don't understand why. Rust does _not_ have an Either type. In fact, Rust's success is a great example of how Either is unnecessary. What Rust does have is a Result<T,E> type, and the lack of a more generically-named Either type was an intentional decision (with pretty much the same rationale that I've been giving).
>>>>>  
>>>>> -Kevin Ballard
>>>>>  
>>>>> On Tue, Jan 26, 2016, at 09:25 AM, Developer wrote:
>>>>>> Which is why I hope the proposal doesn't come off as "let's play copycat".  That said, its success in languages that share either paradigms or common heritage with Swift cannot be discounted so easily.  Rust, for example, with no exceptions mechanism in place has used an Either to great effect.  F# with one in place offers the even more general Core.Choice that is often wrapped by framework authors and augmented with library-specific semantics as they see fit.  C++ (through boost) and D chose to implement this pattern without tags, and made the type variadic instead.  In all cases the result is the same: An increase in the power of each language, a new class of declarative programs being written, and richer libraries because of all these.
>>>>>>  
>>>>>> Currently, swift does not have the necessary language features to produce a variant, nor does it have the ability or the desire to factor this out with a structural typing scheme (see the last round of discussions).  So I see inclusion as the next most logical path.
>>>>>>  
>>>>>> If 3rd party packages are supposed to be first-class, then I have no problem dropping this.  But for now if I import two packages that both export this type I have no recourse other than to drop one or the other or risk linker errors or needless qualification that reduces readability and muddies intent.  A stronger module system or a stronger inclusion/exclusion mechanism invalidates one of our core motivations - to reduce duplicate implementations - but for now I don't see movement on that front.
>>>>>>  
>>>>>> ~Robert Widmann
>>>>>>  
>>>>>> 2016/01/26 10:59、Chris Lattner <clattner at apple.com <mailto:clattner at apple.com>> のメッセージ:
>>>>>>  
>>>>>>>> On Jan 25, 2016, at 11:20 PM, Developer <devteam.codafi at gmail.com <mailto:devteam.codafi at gmail.com>> wrote:
>>>>>>>>  
>>>>>>>> The proposal does not exist because it is "hard or bad" to define the type, but because it factors out a common pattern.  
>>>>>>>  
>>>>>>> I know you intend that to be a positive statement, but design patterns are not always seen as a good thing.  See the criticism section of: https://en.m.wikipedia.org/wiki/Software_design_pattern <https://en.m.wikipedia.org/wiki/Software_design_pattern> for example.
>>>>>>>  
>>>>>>> We have a good language feature (enums/ADTs) that makes the win of Either extremely small or a loss (when you factor in the loss of specificity for a problem domain).
>>>>>>>  
>>>>>>> The bar for getting something into the stdlib is very high, and intentionally so.  Merely existing in some other language isn't enough, it needs to pull its weight given the context of Swift, and even there it needs to have strong justification.  Swift is intentionally designed so that third party packages can be on the same level as the standard library.
>>>>>>>  
>>>>>>> -Chris
>>>>>>>  
>>>>>>>  
>>>>>>>  
>>>>>>>  
>>>>>>>  
>>>>>>>  
>>>>>>>> Adding language features on top of it should only serve to increase the power of the pattern, not decrease the effectiveness of the data type.  An Either with optional projections, for example, is literally the partial projection functions (called in Haskell [sometimes] fromLeft and fromRight).
>>>>>>>>  
>>>>>>>>  
>>>>>>>> ~Robert Widmann
>>>>>>>>  
>>>>>>>> 2016/01/26 2:02、Chris Lattner <clattner at apple.com <mailto:clattner at apple.com>> のメッセージ:
>>>>>>>>  
>>>>>>>>>  
>>>>>>>>>> On Jan 25, 2016, at 10:27 PM, Developer via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>>>>>>>  
>>>>>>>>>> Are you opposed to the name or the semantics?
>>>>>>>>>>  
>>>>>>>>>> I will not accept a revision that reduces the level of abstraction of the current proposal.  I will, however, accept name changes.  Result, though, I believe is out of the question.  It strongly implies a common but pointed set of semantics that discourage thinking of this type as data and more as an alternative to throws.  I do not wish to emphasize the error case, or the theoretical case, I wish to encourage the general case.  We must remember that despite Rust's success, they do not have to live alongside an exceptions mechanism like Either does.
>>>>>>>>>  
>>>>>>>>> Here is my concern:  Swift enums should be good enough that we don’t need an Either type.  If defining your own custom enum is hard or bad, then we should fix that.
>>>>>>>>>  
>>>>>>>>> There are a number of concepts floating around that would make enums better in various ways.  One specific one would be to synthesize optional accessors that line up with enum cases.
>>>>>>>>>  
>>>>>>>>> What will the advantage of Either be once enums get even more fully baked?
>>>>>>>>>  
>>>>>>>>> -Chris
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160126/14f7448f/attachment.html>