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

[Developer]

Perhaps we can imply more semantics with a name, but not those specifically already covered by throws.  For example, I've become fond of this variant of late

enum Choice<This, That> {
    case First(This)
    case Second(That)
}

Then this little tree example becomes more clear in my opinion:

func treeMe() -> Choice<(Choice<Tree, Int>, Int), Int> {
    return .First(.First(tree), sourcePos)
}

~Robert Widmann

2016/01/26 2:24、Dmitri Gribenko via swift-evolution <swift-evolution at swift.org> のメッセージ:

> On Mon, Jan 25, 2016 at 10:38 PM, Rob Mayoff via swift-evolution
> <swift-evolution at swift.org> wrote:
>> For example:
>> 
>> return .Right(.Right(tree), sourcePos)
>> 
>> The outer Right means Success; the inner Right means the right-hand branch
>> of an alternation operator (I think).
> 
> Your example is a perfect illustration of the problem with Either --
> it does not have domain-specific semantics attached, and thus
> compromises readability.
> 
> You had to add an extra sentence to explain what a supposedly simple
> line of code does, and even then you had to add "I think", which I
> understood you used to express uncertainty about the explanation.  I
> don't think promoting this kind of coding style is a goal for Swift.
> 
> Dmitri
> 
> -- 
> main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
> (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution