<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 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></body></html>