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

[Craig Cruden]

What you want in the general language is important base types - generic implementations - building blocks…. things that allow different 3rd party libraries to interoperate….  

I would argue that Result is an application level - a specialized case…. that would not be used to communicate between 3rd party libraries and could easily be an external library that is imported and thus would just be bloat in the standard library.  It is just a wrapped exception.  Which up to this point people have said I want Result type not either but then they give nothing special to Result for anything to help simplify things like validation.

You are saying it should be Result, but you have not given Result anything special - something that makes validation more concise - and chained together.  And if you did give it an implementation it is going to be very specialized and not useable if the validation were anything but the utmost generic “result type”.   Someone will write result and it will handle errors, but then someone else has more requirements such as not everything is an error - there are errors, there are confirmations (warnings that the user has to confirm), warnings (informational), etc.

Either is more in line with Int, Float, Bool, and tuples.  Ideally you would want to the type system to handle it (as in Ceylon) which is 99% more work/impact to do it - but Either provides a starting point until that is implemented.  Usually when implementing things you want to implement what will handle the most use cases, with the least effort (80% of the way there) [in this case a single value], then the next iteration you come back and you implement something that gets you 98% there (Either), then you come back and implement a fully baked solution.  

Result is so specific that if you wanted to pass in a union / either into a function (i.e. either) you would have to actually type it as result - but then it is not a result.

Now if there were a multi-tier packaging - core, core-extended, incubation, and 3rd party.  Where core, core-extended, incubation were officially sanctioned and uniquely named… you could have the import locations where they come from as standard and only have to add an “import xxx” at the top and the package manager go out and fetch core-extended and incubation [3rd party you would have to specify the repository]…… THEN you could place the Either in something like core-extended until it is replaced with a fully baked type system (deprecated at that point).   Failing that you are going to have any functional paradigm library each implementing their own Either - each not being able to communicate with each other.  

Things that could be implemented without changes to the compiler would start out as a 3rd Party library, then if they wanted to move they would apply to be sanctioned and move to incubation which would require a community driven review to make sure the outline is good (i.e. experimental).  Once they are fully baked they would move to core-extended libraries.  These sanctioned libraries would be small in nature and be specialized (i.e. functional data structures, collections, functional data types, etc.) and not overlapping (to the extent possible).  An Either type would fit nicely into core-extended if that option were available and be the base for any 3rd party libraries (until or unless something in core used it).


> On 2016-01-30, at 0:13:25, Erica Sadun via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Jan 29, 2016, at 9:53 AM, Dave Abrahams via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> 
>> on Thu Jan 28 2016, Craig Cruden <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> So to summarize….
>>> 
>>> Either is too specialized and thus not a good add…
>> 
>> I would say the opposite; what most people think of as Either is not
>> specialized enough, because it has no concrete semantics attached.
> 
> +1.
> 
> Result has a specific compelling use-case in threaded completion blocks.
> 
> -- E
> 
> 
> _______________________________________________
> 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/20160130/90122d1d/attachment.html>