<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">Le 3 mai 2017 à 12:06, Jose Manuel Sánchez Peñarroja via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; a écrit :</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><span style="color: rgb(69, 69, 69); font-family: 'Helvetica Neue';" class="">There is currently a discussion open about throws, but it seems that the idea would be to add optionals to throws. In my opinion it would be much better to just get rid of all the throw error system.</span><br class=""><div style="margin: 0px; line-height: normal; font-family: 'Helvetica Neue'; color: rgb(69, 69, 69); min-height: 14px;" class=""><br class=""></div><div style="margin: 0px; line-height: normal; font-family: 'Helvetica Neue'; color: rgb(69, 69, 69);" class="">I think an *Result&lt;ErrorT, T&gt;* type would provide much better error handling than the current solution:</div><div style="margin: 0px; line-height: normal; font-family: 'Helvetica Neue'; color: rgb(69, 69, 69); min-height: 14px;" class=""><br class=""></div></div></div></blockquote><div><br class=""></div><div>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.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="margin: 0px; line-height: normal; font-family: 'Helvetica Neue'; color: rgb(69, 69, 69);" class="">- It would work just like Optional. We could use ?, ??, map, all those concepts that are already in use. A Result would basically be like a missing value with an error attached. *mapError* could also be added to transform error types to the appropriate value.&nbsp;</div></div></div></blockquote><div><br class=""></div><div>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.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="margin: 0px; line-height: normal; font-family: 'Helvetica Neue'; color: rgb(69, 69, 69);" class="">- We would have a specific error type. Right now throws just returns an *Error*, which is basically a glorified *Any*. Anything can go in there, and it's really hard (or impossible) to know if we are dealing with all the possible options. a Result type would enforce a specific error, so we would gain type safety and we could be sure we are dealing with all the cases.</div></div></div></blockquote><div><br class=""></div><div>This issue can be resolved with typed throw. No need to break all existing code and rewrite the error handling for that.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="margin: 0px; line-height: normal; font-family: 'Helvetica Neue'; color: rgb(69, 69, 69);" class="">- It would simplify everything. We could get rid of *try*, *try?*, *throws*, *rethrows*, *do … catch*.</div></div></div></blockquote><div><br class=""></div>All error handling pattern have a intrinsic complexity. I don’t see how having to call mapError after each call will make thing easier.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="margin: 0px; line-height: normal; font-family: 'Helvetica Neue'; color: rgb(69, 69, 69);" class="">- It could be used asynchronously by just passing the *Result* value. Right now there is a different mechanism for handling async and sync calls. The sync calls have all the *throws*, *rethrows*, must be taken care with *try* and *do … catch*, while in a callback you just send the error.</div></div></div></blockquote></div><br class=""></body></html>