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

[Developer]

Unfortunately, it is tied down to quite a few functional concepts (assuming you mean the Scalaz version of Validation).  For starters (apologies, I misspoke in the last reply), it’s only an Applicative and the standard library only provides Functor and Monad-like concepts.  On top of that, errors will have to pass through a Semigroup, something only Swiftz provides at the moment.

Seems the most extra power you can get is `Result<T>` at the current level of abstraction the Standard Library is at.

> On Jan 23, 2016, at 6:41 PM, Craig Cruden <ccruden at novafore.com> wrote:
> 
> I would think that if Either is in core — and Validation is not to dependent on other functional concepts (too deeply tied to the rest of Swiftz) — and being a very core concept for any application that it would be bundled with Either in standard libraries as well.  Pretty well every business application — large or small — functional or not — would benefit from a very easy /non-verbose validation mechanism. 
> 
> I view Either conceptually as part of the contract that a function provides (normal validation; e.g. Person’s birth cannot be future-dated) which is expected as part of the functions process…. (and are expected and will be dealt with by whatever is calling it)…. while Exceptions are for exceptional circumstances / technical failings that may not be expected during normal operation such as a catastrophic fail (e.g. Server not found).  An Either/Validation business validation would be returned in a message on the same server or to a calling service, while technical failings might do things like fail-over.  
> 
> Not sure if I am expressing myself correctly.
> 
> 
> 
> 
>> On 2016-01-23, at 13:32:06, Developer <devteam.codafi at gmail.com> wrote:
>> 
>> Yes, you definitely can use this Either to recover the Validation monad a la Scala.  I think I have to draw up an implementation and submit it to Swiftz!
>> 
>> ~Robert Widmann
>> 
>> 2016/01/22 23:45、Craig Cruden <ccruden at novafore.com> のメッセージ:
>> 
>>> I was reading the proposal and I have to admit I do like Either and have used it extensively in Scala for normal exceptions (business validations) leaving exceptions to … exceptional circumstances.   If I went back I think I could get rid of quite a bit of stuff if I had put more thought into it.
>>> 
>>> When it comes to validations though I was wondering how you saw it coming together:  
>>> 
>>> i.e. you have a set of validations that you run (independent validations) where after you finished if any of them has a validation you just want a list of business exceptions.  
>>> 
>>> The other scenario I could see is dependent validations where certain validations you want to skip because a validation that it was dependent on failed - i.e. you don’t want to be flooded with other validations which occur solely due to an earlier failed validation.  (i.e. concise execution of a list of validations or something like that).
>>> 
>>> 
>>> 
>>> 
>>> 
>>>> On 2016-01-21, at 10:17:34, Developer via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 
>>>> Hey all,
>>>> 
>>>> 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
>>>> 
>>>> ~Robert Widmann
>>>> 
>>>> 2016/01/09 14:19、Developer <devteam.codafi at gmail.com> のメッセージ:
>>>> 
>>>>> Because the last discussion, while substantive and very much appreciated, did not debate the proposal much, I'd like to begin discussion anew about the addition of an Either type to the Swift Standard Library.  The proposal can be found here (https://github.com/apple/swift-evolution/pull/67#issuecomment-170269481) and a link to the root our previous round of discussion is here (https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001394.html).
>>>>> 
>>>>> Thanks all!
>>>>> 
>>>>> ~Robert Widmann
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>