[swift-evolution] Replace throws with Result

[Jean-Daniel]

> Le 3 mai 2017 à 16:12, Jose Manuel Sánchez Peñarroja via swift-evolution <swift-evolution at swift.org> a écrit :
> 
>> At what cost ? Today, the error handling is barely zero-cost thanks to the swift calling convention. Having a generic return type will not only prevent calling convention optimization, but it will also add cost to all the return types as they will have to embed a discriminator.
> 
> 
> I guess I’m thinking more in terms of usage and elegancy than performance. I don’t know which implications this might have.
> 
>> Is it really a benefit ? Working with functions that returns an optional (and can throw) will be far more complex as we will have to deal with 2 levels of unwrapping, one for the error, and a second one for the returned value.
> 
> 
> I think it would make very little sense to return a Result<ErrorT, Optional<T>>. Just like it doesn’t make much sense to return a Optional<Optional<T>>. It could still happen at some point, but the optional could be upgraded to Result and then everything flattened.

Why that ? How I am supposed to fetch a nullable value from a database for instance and make a distinction between the value exists but is null and there where an error while accessing the data ? 

How should I represent such API if Result<DataBaseError, String?> is not the way to go ?

>> All error handling pattern have a intrinsic complexity. I don’t see how having to call mapError after each call will make thing easier.
> 
> In my opinion it’s easier to learn how optional works, and then use that knowledge for Result, instead of learning 2 different patterns for similar things. Optional can be used for computations where the error is obvious (like Array.first), and Result when more information is needed. Also, Result is not something very original. There are already some implementations of this for Swift, and it is widely used in Haskell (Either) and other languages for dealing with errors.

Not a very convincing argument as Haskell is a niche language compare to the languages that use try/catch/throw like Java, C++, C#, …

> To be honest I never thought this would happen, as it involves a lot of breaking changes, but I expected to have a little discussion to see how feasible it would be in the long run.