<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="">On Dec 24, 2015, at 7:51 PM, Alejandro Martinez <<a href="mailto:alexito4@gmail.com" class="">alexito4@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class="">Absolutely agree Matthew.</div><div class="">My point was that if this is the temporary tradeoff that we have to support for me is worth it. Having typed throws looks like a great next step to improving the current error system.</div><div class="">Curious to see your ideas about that ;)</div><div class=""><br class=""></div></div></div></blockquote><div><br class=""></div><div>Agree with you on that. I think a proposal for proper error conversion during propagation could actually follow this one pretty quickly so we may not have to wait too long. I am hoping it is possible both could make it in the Swift 3 timeframe if both are accepted.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class="">Cheers,</div><div class=""><br class="">Sent from my iPad</div><div class=""><br class="">On 24 Dec 2015, at 14:26, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div class=""><br class=""><br class="">Sent from my iPad</div><div class=""><br class="">On Dec 24, 2015, at 3:24 AM, Alejandro Martinez <<a href="mailto:alexito4@gmail.com" class="">alexito4@gmail.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div class="">Hi!</div><div class="">I've been following the conversation closely so here are my 2c</div><div class=""><br class=""></div><div class="">TL;TR: +1</div><div class=""><br class=""></div><div class="">After proposing solutions for the concerns about conversions this is a clear +1. Overloading the conversion functions is how it works in Rust and I think is a good tradeoff, even without the magical "try!" That Rust has. Maybe we could explore something like that when Swift give us a macro like system. But for now I will be happy with this.</div></div></blockquote><div class=""><br class=""></div><div class="">Rust actually uses a trait (the Rust equivalent of a protocol) to do this. It isn't possible in Swift because protocols cannot have type parameters like traits can in Rust and there is no other mechanism in Swift with equivalent capability. </div><div class=""><br class=""></div><div class="">This means that Rust's From mechanism is generic and is part of the standard library. It is part of the common vocabulary of Rust programmers. This is a significant advantage over a solution that uses ad-hoc overloading relying on a convention that is likely to vary between teams. Some teams probably won't even be aware of the possibility to adopt such a convention if it isn't part of our common vocabulary.</div><div class=""><br class=""></div><div class="">Here is what the Rust documentation has to say about this:</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><font face="UICTFontTextStyleTallBody" class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><code style="box-sizing: border-box; word-wrap: break-word; padding: 0px 2px;" class="">From</code> is very useful because it gives us a generic way to talk about conversion <em style="box-sizing: border-box;" class="">from</em> a particular type <code style="box-sizing: border-box; word-wrap: break-word; padding: 0px 2px;" class="">T</code> to some other type (in this case, “some other type” is the subject of the impl, or <code style="box-sizing: border-box; word-wrap: break-word; padding: 0px 2px;" class="">Self</code>). The crux of <code style="box-sizing: border-box; word-wrap: break-word; padding: 0px 2px;" class="">From</code> is the <a href="https://doc.rust-lang.org/std/convert/trait.From.html" style="box-sizing: border-box; text-decoration: none;" class="">set of implementations provided by the standard library</a>.</span></font></blockquote></div><div class=""><br class=""></div><div class="">Swift is not Rust and I personally believe a different approach to handling error translation during propagation would be more Swifty for a number of reasons. I believe that would be the case even if we had macros and protocols with type parameters. I am continuing to think about this and will probably submit a proposal if / when David's proposal is accepted.</div><div class=""><br class=""></div><div class="">IMO it is very important that we have a standard mechanism for translating errors during propagation.</div><div class=""><br class=""></div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class=""><br class=""></div><div class="">The most important thing to remember is that this changes will not affect people that prefers the untyped throws, as they can continue doing it like now. I think this is really important as will allow us to ignore typed errors when writing prototyping code, but it will give the option to improve the safety of our code when is time for that.</div><div class=""><br class=""></div><div class="">Thanks for the proposal and the interesting discussion.</div><div class=""><br class=""><div class="">Sent from my iPad</div></div><div class=""><br class=""></div><div class="">PS: i've been playing on porting the example from Rust errors page to Swift. </div><div class=""><a href="http://alejandromp.com/blog/2015/12/23/rust-error-handling-swift-script/" class="">http://alejandromp.com/blog/2015/12/23/rust-error-handling-swift-script/</a></div><div class="">Will be interesting to try it again with the changes from this proposal ;)</div><div class=""><br class="">On 23 Dec 2015, at 05:58, Thorsten Seitz via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div class=""></div><div class="">David's proposal looks good enough for me.</div><div class=""><br class=""></div><div class="">With regards to Matthew's worry of cluttering the code with conversion I'd like to remark that this conversion code should only live on the border of your API (the facade), so it should probably not be too invasive to your business logic.</div><div class=""><br class=""></div><div class="">-Thorsten </div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class="">Am 22.12.2015 um 20:08 schrieb Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>>:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 22, 2015, at 12:09 PM, David Owens II <<a href="mailto:david@owensd.io" class="">david@owensd.io</a>> wrote:</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=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 22, 2015, at 9:50 AM, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> wrote:</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="">Unfortunately, I don’t see a way to make it safe. You had to use fatalError in a default case to make it work. An alternative would have been to include an ‘UnknownError’ case in ‘PublishedError’. Neither is not an acceptable solution IMO.<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">I need the fatalError() because the sample is a working example in Swift today. If we had typed errors, this would simply work:</div><div class=""><br class=""></div><div class=""><div class=""><font face="Menlo" class=""> static func from<T>(@autoclosure fn: () throws InternalError -> T) throws PublishedError -> T {</font></div><div class=""><font face="Menlo" class=""> do {</font></div><div class=""><font face="Menlo" class=""> return try fn()</font></div><div class=""><font face="Menlo" class=""> }</font></div><div class=""><font face="Menlo" class=""> catch InternalError.Internal(let value) {</font></div><div class=""><font face="Menlo" class=""> throw PublishedError.Converted(value: value)</font></div><div class=""><font face="Menlo" class=""> }</font></div><div class=""><span style="font-family: Menlo;" class=""> }</span></div></div><div class=""><br class=""></div><div class="">This states that the only closure accepted is one that throws an <i class="">InternalError</i>. </div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Ok, so you suggest writing a specific overload for each combination of error types that are convertible. Got it. Not sure why I didn’t think of overloads. I was too focused on a general try function dispatching to an initializer.</div><div class=""><br class=""></div><div class="">That is indeed safe and I can live with it. Thanks for taking the time to work through these examples with me and help to identify patterns that address my concerns!</div><div class=""><br class=""></div><div class="">I still find it unfortunate that this is in the realm of a pattern though. IMO it would be much better if it was part of the common Swift vocabulary, either as a language feature or a library function but that isn’t possible as a generic implementation isn’t possible.</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 class=""><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">This top level `from` example also brings up a couple of points that I don’t recall being addressed in your proposal. Specifically, the interaction of typed errors with generics and type inferrence.</div></div></div></blockquote><div class=""><br class=""></div><div class="">I call out in the proposal that errors work with generics no differently than other types.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Great, I must have missed 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 class=""><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">I still consider this to be an unresolved concern. I would like to have a <b class="">safe</b> way to perform error conversion during propagation without cluttering up my control flow and seriously degrading readability. This is a problem that <i class="">can</i> and <i class="">has</i> been solved in other languages. IMO it is should be considered an essential element of a proposal introducing typed errors.</div></div></div></blockquote><br class=""></div><div class="">When Swift has a macro as powerful as Rust, then this is a solved problem as well. However, Swift isn’t there yet. </div></div></div></blockquote><div class=""><br class=""></div><div class="">I would prefer a solution to this that didn’t require macros which would fit better in Swift. This feature is buried in the `try!` macro in Rust as Rust doesn’t have built-in language level error handling support. </div><div class=""><br class=""></div><div class="">Swift already has `try` built into the language. IMO it would be better to have it handled by the built-in language level error handling support in Swift. That seems like the more “Swifty” approach. We could have a Swift macro `tryAndConvert` or something, but that seems inelegant.</div><div class=""><br class=""></div><div class="">We’ve gone back and forth on this quite a bit but nobody else has chimed in. I’m curious to hear what others thing. I would love it if any lurkers would jump in and comment!</div><div class=""><br class=""></div><div class="">Matthew</div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=1MXK54sosN3xru3iYcLt0oBZ2w20i49gyogXctgrspeU2d2z4MNrh9O6J3NMuULzMf21oQ7ifuAS206zq5zWUyuFZ1YVEzYKn5ap56R7E7nUmvRNC4sopAnUL02lMP8vI-2BbZ1h3-2FxxrzoHqlvdgp8Y-2FWqMO-2FC8hpk-2FKWYLqi8ueH1KN5NlwbPFPnUzeKpk1xPm3-2FTyU4BQGlYF6FO-2FLRXDd3aNBVUmeSmfJ4lL7XGDk-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
</div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=ugfoipfLFYQJoLOuZfhEMRzWwNIL3Gkut5GUvNxqU0fgcbC-2B9TevR-2BKPEwcdeFC9EZ5WKGGiXE4skDWS2GKlSEUbfySnpzolEvCHFHjMMulxMZvCjrnamLZRs0ac9J22EJ8j1B6V3rxm6Kinwc-2Fh8alMZbb8QPnw1A-2FjI-2BItzrM1GQ9TZ-2F-2FIAS2-2BaVCBlu1JqCcyR-2BokX5kQmltLwzSpsZxI2S3QTjlPRRm5Tl9lNqQ-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
</div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></blockquote></div></blockquote></div></div></blockquote></div><br class=""></body></html>