<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);">Hi David</span></div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);">I started reading your proposal and I have a couple of questions. </span></div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);">In the Enum Base ErrorType example you mentioned that it requires a "catch { }" clause. However the code is already covering the two possible Enum values (OffBy1 and MutatedValue). Why is the "catch { }" required? I typed that code into a playground and I did not get any errors. Are you saying that because the Enum type could add a value in the future?</span></div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);">Also, you proposed the catch clause to use error as the name of the constant holding the error. Wouldn't it be better to let the programmer decide the name rather than hard coding it to use error? For example:</span></div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);">catch e where e.value == 0 { print("0") }</span></div><div id="AppleMailSignature"><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);">catch e where e.value == 1 { print("1") }</span></div><div><span style="background-color: rgba(255, 255, 255, 0);">catch { print("nothing") }</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">Thank you </span></div><div><span style="background-color: rgba(255, 255, 255, 0);">Ricardo</span></div></div><br>Sent from my iPhone</div><div><br>On Dec 18, 2015, at 1:36 PM, David Owens II via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<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 18, 2015, at 9:41 AM, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> wrote:</div><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class=""><br class=""></div><div class="">I’m not asking for you to speak for them. But I do think we need to learn from communities that are having success with typed error handling. Your proposal would be stronger if it went into detail about how it would avoid the problems that have been encountered in other languages. The experience of Rust could help to make that case as it is concrete and not hypothetical.</div></div></div></blockquote><div><br class=""></div><div>Sure, it could. It’s also anecdotal. It’s not necessarily true that something that works well in one context works well in another. It’s good to note that typed errors are wholly considered bad, but I’m not sure how much further we need to go then that. If you have specifics, then I could probably add them as an addendum to the proposal.</div><br class=""><blockquote type="cite" class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">My understanding is that Rust uses static multi-dispatch to do this. I don’t believe it has anything to do with structural sum types. Rust error handling uses a Result type with a single error case: <a href="http://doc.rust-lang.org/book/error-handling.html" class="">http://doc.rust-lang.org/book/error-handling.html</a>.</div></blockquote><div><br class=""></div><div>That example takes you through many of the options available. In the end, you end up at the sum-type for the error:</div><div><pre class="rust-example-rendered rust" style="box-sizing: border-box; font-family: 'Source Code Pro', Menlo, Monaco, Consolas, 'DejaVu Sans Mono', monospace; word-wrap: break-word; border: 0px; white-space: pre-wrap; padding: 11px; margin-top: 20px; margin-bottom: 20px; font-size: 14px; word-break: break-all; overflow: auto; line-height: 1.45; background-color: rgb(247, 247, 247); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; position: relative;"><span style="color: rgb(51, 51, 51);" class=""><span class="kw" style="box-sizing: border-box; color: rgb(137, 89, 168);">fn</span> <span class="ident" style="box-sizing: border-box;">search</span><span class="op" style="box-sizing: border-box;"><</span><span class="ident" style="box-sizing: border-box;">P</span>: <span class="ident" style="box-sizing: border-box;">AsRef</span><span class="op" style="box-sizing: border-box;"><</span><span class="ident" style="box-sizing: border-box;">Path</span><span class="op" style="box-sizing: border-box;">>></span>
(<span class="ident" style="box-sizing: border-box;">file_path</span>: <span class="kw-2" style="box-sizing: border-box; color: rgb(66, 113, 174);">&</span><span class="prelude-ty" style="box-sizing: border-box; color: rgb(66, 113, 174);">Option</span><span class="op" style="box-sizing: border-box;"><</span><span class="ident" style="box-sizing: border-box;">P</span><span class="op" style="box-sizing: border-box;">></span>, <span class="ident" style="box-sizing: border-box;">city</span>: <span class="kw-2" style="box-sizing: border-box; color: rgb(66, 113, 174);">&</span><span class="ident" style="box-sizing: border-box;">str</span>)
<span class="op" style="box-sizing: border-box;">-></span> <span class="prelude-ty" style="box-sizing: border-box; color: rgb(66, 113, 174);">Result</span><span class="op" style="box-sizing: border-box;"><</span><span class="ident" style="box-sizing: border-box;">Vec</span><span class="op" style="box-sizing: border-box;"><</span><span class="ident" style="box-sizing: border-box;">PopulationCount</span><span class="op" style="box-sizing: border-box;">></span>, <span class="ident" style="box-sizing: border-box;">CliError</span><span class="op" style="box-sizing: border-box;">></span> {
</span><font color="#8959a8" class="">...</font><font color="#333333" class="">
}</font></pre><div class="">It’s the CliError which is defined as:</div><div class=""><pre class="rust-example-rendered rust" style="box-sizing: border-box; font-family: 'Source Code Pro', Menlo, Monaco, Consolas, 'DejaVu Sans Mono', monospace; word-wrap: break-word; border: 0px; white-space: pre-wrap; padding: 11px; margin-top: 20px; margin-bottom: 20px; font-size: 14px; word-break: break-all; overflow: auto; line-height: 1.45; background-color: rgb(247, 247, 247); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; position: relative; color: rgb(51, 51, 51);"><span class="kw" style="box-sizing: border-box; color: rgb(137, 89, 168);">enum</span> <span class="ident" style="box-sizing: border-box;">CliError</span> {
<span class="ident" style="box-sizing: border-box;">Io</span>(<span class="ident" style="box-sizing: border-box;">io</span>::<span class="ident" style="box-sizing: border-box;">Error</span>),
<span class="ident" style="box-sizing: border-box;">Csv</span>(<span class="ident" style="box-sizing: border-box;">csv</span>::<span class="ident" style="box-sizing: border-box;">Error</span>),
<span class="ident" style="box-sizing: border-box;">NotFound</span>,
}</pre></div><div class="">The From() function essentially allows the <b class="">try!</b> macro to expand these in a nicer way.</div><div class=""><br class=""></div><div class="">So back to the proposal, one of the key things is to promote the `error` constant throughout the catch-clauses. This means that we can already leverage Swift’s pattern matching to solve this problem:</div><div class=""><br class=""></div></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div><div><div class=""><font face="Menlo" class="">enum Combined {</font></div></div></div><div><div><div class=""><font face="Menlo" class=""> case IO(String)</font></div></div></div><div><div><div class=""><font face="Menlo" class=""> case Number(Int)</font></div></div></div><div><div><div class=""><font face="Menlo" class="">}</font></div></div></div><div><div><div class=""><font face="Menlo" class=""><br class=""></font></div></div></div><div><div><div class=""><font face="Menlo" class="">func simulate(err: Combined) {</font></div></div></div><div><div><div class=""><font face="Menlo" class=""> switch err {</font></div></div></div><div><div><div class=""><font face="Menlo" class=""> case let Combined.IO(string) where string == "hi": print("only hi!")</font></div></div></div><div><div><div class=""><font face="Menlo" class=""> case let Combined.IO(string): print(string)</font></div></div></div><div><div><div class=""><font face="Menlo" class=""> case let Combined.Number(value): print(value)</font></div></div></div><div><div><div class=""><font face="Menlo" class=""> }</font></div></div></div><div><div><div class=""><font face="Menlo" class="">}</font></div></div></div><div><div><div class=""><font face="Menlo" class=""><br class=""></font></div></div></div><div><div><div class=""><font face="Menlo" class="">simulate(Combined.IO("hi"))</font></div></div></div><div><div><div class=""><font face="Menlo" class="">simulate(Combined.IO("io"))</font></div></div></div><div><div><div class=""><font face="Menlo" class="">simulate(Combined.Number(9))</font></div></div></div></blockquote><div><div><div class=""><br class=""></div><div class="">It’s not hard to use Swift’s pattern matching to extract out the inner information on an associated value enum and white the case/catch clauses. So unless I’m missing something, I think Swift already provides a good mechanism to do what you’re asking for, with the caveat that the `error` constant is promoted to be usable in the catch-clauses similar to how the switch-statements work.</div><div class=""><br class=""></div><div class="">Maybe adding this to the proposal would clarify usage?</div><div class=""><br class=""></div></div><blockquote type="cite" class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="">How does this create a fragile API surface area? Adding a new error type to the signature would be a breaking change to the API contract. This is really no different than changing the type of error that can be thrown under your proposal.</div></div></blockquote><div><br class=""></div><div>It’s the same fragility that enums create; this was covered in the criticisms section. The likelihood of adding additional error cases is much greater than a change that would completely change the type of the error.</div><br class=""><blockquote type="cite" class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""><blockquote type="cite" class=""><div class="">I see this functionality as a general limitation in the language. For example, errors are not the only context where you may want to return a type of A, B, or C. There have been other proposals on how we might do that in Swift. If and when it was solved in the general case for type parameters, I can’t foresee a compelling reason why it wouldn’t work in this context as well.<br class=""></div></blockquote><div class=""><br class=""></div><div class="">That makes sense in some ways, but I don’t think it’s unreasonable to ask for some analysis of whether a better design for typed errors would be possible if we had them. IMO it’s pretty important to get the design of typed errors right if / when we add them. If we don’t it will be considered a major mistake and will lead to a lot of less than desirable outcomes down the road.</div><div class=""><br class=""></div><div class="">I also think typed errors may be one of the more important use cases for structural sum types of some kind. If we are able to show that design problems that<span class="Apple-converted-space"> </span><b class="">cannot</b><span class="Apple-converted-space"> </span>be solved without them<span class="Apple-converted-space"> </span><b class="">can</b><span class="Apple-converted-space"> </span>be solved with them that might influence whether they are added or not. It might also influence<span class="Apple-converted-space"> </span><b class="">when</b> it makes sense to add support for typed errors to the language.</div></div></blockquote><div><br class=""></div><div>The problem can be solved without implicitly generated sum types though. The design of typed errors, as proposed, is to be consistent with the Swift type system today. Regardless, I’ve added a response in the “cirticisms” section that hopefully addresses this in some manner - basically, yes it would be helpful, but out of scope for this proposal.</div><br class=""><blockquote type="cite" class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">That approach would make catch clauses rather clunky by nesting errors inside of associated values. If you’re advocating for this approach do you have any ideas on how to streamline syntax for catching them?</div></blockquote><br class=""></div><div>See above example. Does that address this concern?</div><div><br class=""></div><div>-David</div><br class="">
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=pLP9geT8Np1lYPUE1Mzp7-2FNnYod8hGw1uYpGMl3J8kPfemorCIFdDbfM3blYQgCihSOnNqcqQsXIvKruJ15jgR4LOF31SB3KaT299Y2hiAb3dVopA874YEKi1j-2F-2B361Ja-2BLXFLIar8m1KLNF0zb2vM99VVwIJEVSi8XWCXAGzGhEoUgbzuqfnxZ7QiHDTlAdE-2FJufR0E9MzbI19zYEtj3Q-3D-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>