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

Tue Jan 26 16:01:10 CST 2016

Well yeah, that's why I objected to this proposal. You keep talking as
though you think I agree with you and are just quibbling on the name.
But that's not true at all. You very specifically want to have a type
that's more generic than a Result enum, and I very specifically want to
avoid having a type that's that generic in the stdlib. Hence my vocal
objections.

-Kevin Ballard

On Tue, Jan 26, 2016, at 01:57 PM, Developer wrote:
> Because nowhere in the proposal do we use the words “Result Type”.
>
>> This proposal details the addition of a left-biased sum type to the
>> Swift Standard Library. Earlier attempts at adding this have been too
>> specifically focused on error handling (duplicating functionality
>> throws already provides), whereas this implementation will focus on
>> data, organization, and type safety. We believe that adding the type
>> to the standard library and simultaneously emphasizing its use cases
>> -that is, when you need a type that represents exactly 2 disjoint possibilities-
>> can dispel the confusion caused in other languages and quell the
>> conflict with throws.
>
>> On Jan 26, 2016, at 4:55 PM, Kevin Ballard <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> 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> のメッセージ:
>>>>>
>>>>>>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160126/3d97eb35/attachment.html>