<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>I agree, David's proposal looks good. </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Matthew concerned are interesting, and I think David answered them well.</div><div id="AppleMailSignature"><br>Pierre</div><div><br>Le 23 déc. 2015 à 06:58, Thorsten Seitz via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> a écrit :<br><br></div><blockquote type="cite"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div></div><div>David's proposal looks good enough for me.</div><div><br></div><div>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><br></div><div>-Thorsten </div><div><br></div><div><br></div><div><br>Am 22.12.2015 um 20:08 schrieb Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><br class=""><div><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><br class=""></div><div>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><br class=""></div><div>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><br class=""></div><div>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><br class=""></div><div>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><br class=""></div><div>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><br class=""></div><div>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><br class=""></div><div>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><br class=""></div><div>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;">
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=ST9LHNQ2kYRKURQJ7G-2FmGCudH8brFLVBGfh-2Becw1t9iJBgu-2FQLuVZG1AYJuQE8V-2FI0g-2FYjUb6aRH3VslT9nHMmoi7AE6tHmSwBX9kdkfvaY6kqF-2FHr5NEry6B2qwdeb81XhyUEse6CH2-2BiCyq-2B4pUvmzDOHy2IAXQ-2Bg6MEWwvPT93iAe6PWqyeznCJAKDE-2BAsFuI5oX-2FRBxl6WpQQm9Y-2B3QWOHauil-2Fxd0HKfmtYFSo-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;">
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>