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

[Craig Cruden]

I ran into a scenario in old java code - where it parses things in (global to the whole system) where I would probably have used Either over Optional to store the date - if I were working in a functional language (and yes there are “ways” to handle it other than Either - but exceptions are rather heavy, maybe an enumeration type wrapping date - but even then…).

The date field has to hold a valid date.  The parser is parsing leniently as to not throw unnecessary errors - it was either lenient, pass back a null, or blow chunks while parsing).  

So the date passed in was “20092002” and they were expecting the “batch job” to give an invalid date error.  The parsing is global so this would be a special case - which means changing it to string and doing parsing elsewhere as a hack (rather than potentially affecting server wide change in all services).   Dealing with it leniently meant the date reaching the batch job was “20100802” (roll the overflow months).  

What would have been better - is not throwing an exception, and not having an optional since the date could be empty or it could be a valid date - but this is a third case.  

I would have probably just used an Either[String, Date],  Either[enum, Date] where enum is not necessarily an error - it could be a invalid( string) , and empty type, or a date type.  It would allow me to deal with special cases or not….  

Now I know with swift I could create my own “Date” wrapper as an enum with these, but it still fields weird to me.  

Not trying to convince anyone it should be in the standard library at this point, but it is the difference between validation and exceptions.  Exceptions throw up and force you to handle them — or potentially blow up later because it was not handled (i.e. ignored) while this is more the data can either be a date or string.




> On 2016-02-03, at 22:58:59, Evan Maloney via swift-evolution <swift-evolution at swift.org> wrote:
> 
> +1 to Kevin Ballard's response below.
> 
> 
>> There absolutely is a cost. `Result<T>` has a rather intuitive meaning. `Either<T>` has no intuitive meaning whatsoever. It says absolutely nothing about what it means beyond the fact that there are two potential values. As a result, it is a largely useless type whose sole redeeming feature is it allows developers to avoid having to define their own enum, but in most cases that aren't covered by Result<T> you actually want to define your own enum so you can attach meaning to the value.
>>  
>> If it's not obvious, I'm very strongly against having a generic Either type, but I do want a Result<T> or Result<T,E>.
>>  
>> -Kevin Ballard
>>  
>> On Fri, Jan 22, 2016, at 10:22 PM, Developer via swift-evolution wrote:
>>> My overwhelming concern, after having a conversation with Chris, is that implementing a Result<T> means we are strongly implying a particular semantics and use case when we could generalize and abstract for no cost but an extra generic parameter.  In F#, Core.Choice can be used to build a Validation or Result monad, but the converse is impossible.
>>>  
>>> ~Robert Widmann
>>>  
>>> 2016/01/23 1:05、Rob Mayoff via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> のメッセージ:
>>>> Just added a section of motivating examples to the Either proposal.  Ping me if you have any more that I missed ('cause I'm sure I did miss a lot).
>>>>  
>>>> https://github.com/typelift/swift-evolution/blob/either-or/proposals/0024-either.md#motivating-examples <https://github.com/typelift/swift-evolution/blob/either-or/proposals/0024-either.md#motivating-examples>
>>>>  
>>>>  
>>>> Your motivating examples (including all the projects you linked except "Any many more") overwhelmingly use the Either (or similar type) to represent success/failure. I'm not sure there's a single example where the names Left and Right actually make sense in the problem domain. I'm not 100% sure about func alternate in Madness/Alternation.swift. It definitely uses Left/Right to mean Failure/Result, but I couldn't tell if it also uses them as something else. Which makes those names all the more maddening.
>>>>  
>>>> I checked my company's largest Scala project, which is over 300,000 lines. We use Scala's Try/Success/Failure in dozens of places. We use Either/Left/Right once, in a thrown-together report-generating script, which would probably have been written in awk or perl if it didn't need to read binary log files. (The ability of IntelliJ to reliably find all uses of a class or method is not to be underestimated. Hint hint, team Xcode.)
>>>>  
>>>> I think a Result/Success/Failure type is warranted, but I'm very skeptical about generic Either/Left/Right.
>>>>  
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>  
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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