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

[David Waite]

I can’t speak for everyone, but for myself:

I perceive a common Result/Either type as being desired for composability. If I have two libraries that define their own Result/Either/etc. types, my ability to compose functions across those libraries is impacted.

But for myself, this has’t been an impact yet. 

I have a feeling that if Swift 4 adds concurrency as a goal, the language will need some sort of Result or Either then (just like it may add some sort of Promise/Future system). The language may also need to expand the current error system to support these. 

Since my understanding is discussion about concurrency is off the table until after Swift 3, that impacts the ability to discuss the impact possible concurrency solutions to a Result/Either type, similarity to Promise types, and/or impacts the addition of any of these would have to the current error system. 

Personally, I feel I was already shot down right at the beginning of evolution by proposing generator functions partially because they were *close* to concurrency, so I don’t plan to push anything else (even just forward-thinking) about concurrency unless requested :-)

-DW

> On Jan 26, 2016, at 8:59 AM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
> On Jan 25, 2016, at 11:20 PM, Developer <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 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> のメッセージ:
>> 
>>> 
>>>> On Jan 25, 2016, at 10:27 PM, Developer via swift-evolution <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
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution