<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 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><br class=""></div><div>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><br class=""></div><div><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><br class=""></div><div>This states that the only closure accepted is one that throws an <i class="">InternalError</i>. </div><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><br class=""></div><div>I call out in the proposal that errors work with generics no differently than other types.</div><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>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><br class=""></div><div>-David</div><br class=""></body></html>