> Le 3 mai 2017 à 16:12, Jose Manuel Sánchez Peñarroja via swift-evolution > <[email protected]> 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. _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
