<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="">That's fair. The reasoning I read about mentioned making it easier for newcomers, but it's very possible that was a 3rd party opinion (I don't remember). I certainly did not intend to upset anyone.<div class=""><br class=""></div><div class="">Either way, I do still believe that the current placement / syntax isn't entirely clear.<br class=""><div class="">
<div style="color: rgb(0, 0, 0); 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; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class="">-thislooksfun (tlf)</div>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On Dec 27, 2016, at 4:09 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">Offlist on purpose?</div><div class=""><br class=""></div>On Tue, Dec 27, 2016 at 5:03 PM, thislooksfun <span dir="ltr" class=""><<a href="mailto:thislooksfun@repbot.org" target="_blank" class="">thislooksfun@repbot.org</a>></span> wrote:<br class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">Thinking about it logically, it's placement does fit, yes.</div></blockquote><div class=""><br class=""></div><div class="">:) That's all one can ask.</div><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">I'm not debating that the current placement is logical once you get used to it, but on a related note, so are ++ and --, which were removed to make the language easier and more immediately intuitive for new programmers.</div></blockquote><div class=""><br class=""></div><div class="">Bringing up ++ and -- on the list just makes everyone unhappy; also, classical for;; loops. It's like Godwin's law for Swift Evolution :P</div><div class=""><br class=""></div><div class="">But FWIW, making it easier for new programmers was not the whole rationale (or, if I recall, even a large part of it). There's a whole school of thought in language design that removing ++ and -- and for;; loops is the _more logical_ thing to do from a modern language design perspective. I don't have the link, but there was an article recently evaluating Rust, Go, Swift, and a bunch of other C-family languages for the "quality" of their design. An opinionated piece, to be sure, but having ++ and for;; were regarded as negatives that languages would lose points for. So let's be clear that it's not a way of thinking that originated from Swift wanting to help beginners, nor is it even limited to Swift at all.</div><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">My only point was that if they are willing to go to such lengths to make the language easy to understand as to remove a very well known feature like the incremention and decremention operators, maybe the placement of `throws` should be reviewed to make sure it's also intuitive.<br class=""><div class="">
<div style="letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; word-wrap: break-word;" class=""><br class="">-thislooksfun (tlf)</div>
</div><div class=""><div class="h5">
<br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 27, 2016, at 3:58 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="m_-9049357509343812772Apple-interchange-newline"><div class=""><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><div class="">Agree, it doesn't seem to read naturally at first glance.</div><div class=""><br class=""></div><div class="">However, one way perhaps to think about the rationale for this is that `throws` does "fit" logically between the parameters and the return type: a function that throws might take certain arguments and, by throwing, never return a value of the stated return type. In that perspective, `throws` could be justified in its current position interposed between the input and the desired output.</div><div class=""><br class=""></div><div class=""><br class=""></div>On Tue, Dec 27, 2016 at 4:51 PM, thislooksfun via swift-evolution<span class="m_-9049357509343812772Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-<wbr class="">evolution@swift.org</a>></span><span class="m_-9049357509343812772Apple-converted-space"> </span>wrote:<br class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class="">If some form of explicitly typed errors is added, my initial problem goes away. The only reason I suggested the move in the first place, is that a combination of `throws` and return (-> T) statements makes it<span class="m_-9049357509343812772Apple-converted-space"> </span><i class="">look</i> like there is already explicitly typed errors, especially to those of us coming from Java.<br class=""><div class=""><div style="letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word" class=""><br class="">-thislooksfun (tlf)</div></div><div class=""><div class="m_-9049357509343812772h5"><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 27, 2016, at 3:41 PM, Karl via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class="m_-9049357509343812772m_8597572834478154638Apple-interchange-newline"><div class=""><div style="word-wrap:break-word" class="">Moving “throws” or changing it to a prefix “throwing” as was originally suggested are relatively minor, reasonable improvements.<br class=""><div class=""><br class=""></div><div class="">We do need to consider if it restricts future language evolution (such as potentially listing all of the thrown errors), so that’s why it’s relevant to talk a little bit about that and what are options would be; but I think fundamental, non-backwards compatible changes to how you invoke throwing functions are probably too big to be reasonable.</div><div class=""><br class=""></div></div></div></blockquote></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">I'm -1 on big changes such as suggested as well. The deliberate choice to separate error handling from other code with `do { }` was a deliberate design choice and it'd be very disruptive to break that now. And in terms of just gut feeling, switching over errors and return values at the same time seems like going in the wrong direction.</div><div class=""> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><div class="m_-9049357509343812772h5"><div class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap:break-word" class=""><div class=""></div><div class="">- Karl</div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 27 Dec 2016, at 22:31, Derrick Ho <<a href="mailto:wh1pch81n@gmail.com" target="_blank" class="">wh1pch81n@gmail.com</a>> wrote:</div><br class="m_-9049357509343812772m_8597572834478154638Apple-interchange-newline"><div class="">Right. it should support the normal return type as well as the errors. Here is my revised suggestion.<br class=""><br class="">func foo() throws -> String {}<br class=""><br class="">switch try foo() {<br class="">case .returnValue(let value):<br class="">// do something with value<br class=""><br class="">case .MyEnumErrorFirstError:<br class="">// handle error<br class=""><br class="">default:<span class="m_-9049357509343812772Apple-converted-space"> </span><br class="">// handle NSError<br class="">}<br class=""><div class="gmail_quote"><div dir="ltr" class="">On Tue, Dec 27, 2016 at 1:17 PM Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="">xiaodi.wu@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr" class="m_-9049357509343812772m_8597572834478154638gmail_msg">On Tue, Dec 27, 2016 at 4:03 PM, Derrick Ho via swift-evolution<span class="m_-9049357509343812772Apple-converted-space"> </span><span dir="ltr" class="m_-9049357509343812772m_8597572834478154638gmail_msg"><<a href="mailto:swift-evolution@swift.org" class="m_-9049357509343812772m_8597572834478154638gmail_msg" target="_blank">swift-<wbr class="">evolution@swift.org</a>></span><span class="m_-9049357509343812772Apple-converted-space"> </span>wrote:<br class="m_-9049357509343812772m_8597572834478154638gmail_msg"></div><div dir="ltr" class="m_-9049357509343812772m_8597572834478154638gmail_msg"><div class="gmail_extra m_-9049357509343812772m_8597572834478154638gmail_msg"><div class="gmail_quote m_-9049357509343812772m_8597572834478154638gmail_msg"><blockquote class="gmail_quote m_-9049357509343812772m_8597572834478154638gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I suppose "throws" could be enhanced to produce a compiletime enum<span class="m_-9049357509343812772Apple-converted-space"> </span><br class="m_-9049357509343812772m_8597572834478154638gmail_msg"><br class="m_-9049357509343812772m_8597572834478154638gmail_msg">func bar() throws {<br class="m_-9049357509343812772m_8597572834478154638gmail_msg">throw NSError()<br class="m_-9049357509343812772m_8597572834478154638gmail_msg">throw MyEnumError.firstError<br class="m_-9049357509343812772m_8597572834478154638gmail_msg">}<br class="m_-9049357509343812772m_8597572834478154638gmail_msg"><br class="m_-9049357509343812772m_8597572834478154638gmail_msg">Under the hood each expression passed to "throw" could make something like<br class="m_-9049357509343812772m_8597572834478154638gmail_msg"><br class="m_-9049357509343812772m_8597572834478154638gmail_msg">enum bar_abcdefj_throw {<br class="m_-9049357509343812772m_8597572834478154638gmail_msg">case genericError // all NSError go here<br class="m_-9049357509343812772m_8597572834478154638gmail_msg">case MyEnumErrorFirstError<br class="m_-9049357509343812772m_8597572834478154638gmail_msg">}<br class="m_-9049357509343812772m_8597572834478154638gmail_msg"><br class="m_-9049357509343812772m_8597572834478154638gmail_msg">Where abcdefj is unique characters.<br class="m_-9049357509343812772m_8597572834478154638gmail_msg"><br class="m_-9049357509343812772m_8597572834478154638gmail_msg"><br class="m_-9049357509343812772m_8597572834478154638gmail_msg">This enum would only be visible through the catch blocks which would act like a switch statement.<br class="m_-9049357509343812772m_8597572834478154638gmail_msg"><br class="m_-9049357509343812772m_8597572834478154638gmail_msg">Speaking of switch statements do they currently support "try" expressions?<br class="m_-9049357509343812772m_8597572834478154638gmail_msg"><br class="m_-9049357509343812772m_8597572834478154638gmail_msg">switch try foo() {<br class="m_-9049357509343812772m_8597572834478154638gmail_msg">case .MyEnumErrorFirstError:<br class="m_-9049357509343812772m_8597572834478154638gmail_msg">// handle error<br class="m_-9049357509343812772m_8597572834478154638gmail_msg">default:<span class="m_-9049357509343812772Apple-converted-space"> </span><br class="m_-9049357509343812772m_8597572834478154638gmail_msg">// handle NSError and everything else<br class="m_-9049357509343812772m_8597572834478154638gmail_msg">}<br class="m_-9049357509343812772m_8597572834478154638gmail_msg"></blockquote><div class="m_-9049357509343812772m_8597572834478154638gmail_msg"><br class="m_-9049357509343812772m_8597572834478154638gmail_msg"></div></div></div></div><div dir="ltr" class="m_-9049357509343812772m_8597572834478154638gmail_msg"><div class="gmail_extra m_-9049357509343812772m_8597572834478154638gmail_msg"><div class="gmail_quote m_-9049357509343812772m_8597572834478154638gmail_msg"><div class="m_-9049357509343812772m_8597572834478154638gmail_msg">If I'm not mistaken, `switch try foo()` switches over the return value of foo(); you'd switch over the error in a catch block.</div><div class="m_-9049357509343812772m_8597572834478154638gmail_msg"> </div><blockquote class="gmail_quote m_-9049357509343812772m_8597572834478154638gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"></blockquote></div></div></div><div dir="ltr" class="m_-9049357509343812772m_8597572834478154638gmail_msg"><div class="gmail_extra m_-9049357509343812772m_8597572834478154638gmail_msg"><div class="gmail_quote m_-9049357509343812772m_8597572834478154638gmail_msg"><blockquote class="gmail_quote m_-9049357509343812772m_8597572834478154638gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">The benefit of this approach is that it would be additive. And no source breakage.<br class="m_-9049357509343812772m_8597572834478154638gmail_msg"><br class="m_-9049357509343812772m_8597572834478154638gmail_msg">At the risk of being off topic if there is interest in this I can start a new thread for this.<div class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581HOEnZb"><div class="m_-9049357509343812772m_8597572834478154638m_6634727487067944581h5 m_-9049357509343812772m_8597572834478154638gmail_msg"><br class="m_-9049357509343812772m_8597572834478154638gmail_msg"><div class="gmail_quote m_-9049357509343812772m_8597572834478154638gmail_msg"><div dir="ltr" class="m_-9049357509343812772m_8597572834478154638gmail_msg">On Tue, Dec 27, 2016 at 9:54 AM Haravikk <<a href="mailto:swift-evolution@haravikk.me" class="m_-9049357509343812772m_8597572834478154638gmail_msg" target="_blank">swift-evolution@haravikk.me</a>> wrote:<br class="m_-9049357509343812772m_8597572834478154638gmail_msg"></div><blockquote class="gmail_quote m_-9049357509343812772m_8597572834478154638gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg" style="word-wrap:break-word"><div class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg"><blockquote type="cite" class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg"><div class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg">On 27 Dec 2016, at 13:43, Tino Heth <<a href="mailto:2th@gmx.de" class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg" target="_blank">2th@gmx.de</a>> wrote:</div><div class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg"><div class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg" style="word-wrap:break-word"><div class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg"><div class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg">Imho this is no problem:</div><div class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg">Right now, we basically have "throws Error", and no matter what is actually thrown, we can always catch exhaustive by keeping the statement unspecific.</div></div></div></div></blockquote><div class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg"><br class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg"></div></div></div><div class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg" style="word-wrap:break-word"><div class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg"><div class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg">True, but for me it's more about knowing what a method can throw; currently to know that you need to consult documentation which, while fine, isn't the best way to do that when the compiler could know and it's then up to you whether to let it auto-complete for all throwable types, or just be generic for some or all of them (or pass the buck).</div></div></div><div class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg" style="word-wrap:break-word"><div class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg"><br class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg"><blockquote type="cite" class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg"><div class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg" style="word-wrap:break-word"><div class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg"><blockquote type="cite" class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg"><span class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg" style="font-family:Monaco">myMethod(args:[String:Any]) throws IOError, IllegalArgumentError? { … }</span></blockquote></div>Imho to much confusion with no real benefit:<div class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg">Shouldn't it be up to the caller to decide which errors need special treatment? The library can't enforce proper handling at all.</div></div></blockquote><div class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg"><br class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg"></div></div></div><div class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg" style="word-wrap:break-word"><div class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg"><div class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg">Partly, but it's really just intended to distinguish things that are genuine runtime errors, versus things that shouldn't have happened, i.e- an illegal argument type error shouldn't occur if you're using a method correctly, so it's more like something you might check as an assertion. I should have been more clear that the main difference is in how fix-its might recommend the errors are handled; specific types would produce catch blocks, but optionals might be grouped into a catch-all at the end (e.g- they're special interest that you might not be bothered about), but the compiler would still be aware of them should you decide to add them.</div><div class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg"><br class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg"></div><div class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg">If the distinctions not significant enough though then the "optional" error types could just be ignored for now, I think the more important ability is the ellipsis indicating "plus other errors" so we can specify either exhaustive lists of error types, or keep them open-ended, in which case the types listed are those that would be placed as catch blocks, with the ellipsis indicating that a catch-all is still required (or throw on the current method).</div></div></div><div class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg" style="word-wrap:break-word"><div class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg"><br class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg"><blockquote type="cite" class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg"><div class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg" style="word-wrap:break-word"><div class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg">One thing to note with explicit errors is that we'd basically introduce sum types…</div></div></blockquote></div></div><div class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg" style="word-wrap:break-word"><div class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg"></div><br class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg"><div class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg">Not necessarily; you could think of explicit errors as being doing something like:</div><div class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg"><br class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg"></div><div class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg"><span class="m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406m_7179559898482663862Apple-tab-span m_-9049357509343812772m_8597572834478154638gmail_msg" style="white-space:pre-wrap"> </span>enum MyErrorType {</div><div class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg"><span class="m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406m_7179559898482663862Apple-tab-span m_-9049357509343812772m_8597572834478154638gmail_msg" style="white-space:pre-wrap"> </span>case io_error(IOError)</div><div class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg"><span class="m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406m_7179559898482663862Apple-tab-span m_-9049357509343812772m_8597572834478154638gmail_msg" style="white-space:pre-wrap"> </span>case illegal_argument(IllegalArgume<wbr class="">ntError)</div><div class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg"><span class="m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406m_7179559898482663862Apple-tab-span m_-9049357509343812772m_8597572834478154638gmail_msg" style="white-space:pre-wrap"> </span>case unknown(Error)</div><div class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg"><span class="m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406m_7179559898482663862Apple-tab-span m_-9049357509343812772m_8597572834478154638gmail_msg" style="white-space:pre-wrap"> </span>}</div><div class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg"><br class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg"></div><div class="m_-9049357509343812772m_8597572834478154638gmail_msg m_-9049357509343812772m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg">i.e- boilerplate we could do right now, but would prefer not to, but still allowing it to be handled as an enum.</div></div></blockquote></div></div></div><br class="m_-9049357509343812772m_8597572834478154638gmail_msg"></blockquote></div></div></div><div dir="ltr" class="m_-9049357509343812772m_8597572834478154638gmail_msg"><div class="gmail_extra m_-9049357509343812772m_8597572834478154638gmail_msg"><div class="gmail_quote m_-9049357509343812772m_8597572834478154638gmail_msg"><blockquote class="gmail_quote m_-9049357509343812772m_8597572834478154638gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">______________________________<wbr class="">_________________<br class="m_-9049357509343812772m_8597572834478154638gmail_msg">swift-evolution mailing list<br class="m_-9049357509343812772m_8597572834478154638gmail_msg"><a href="mailto:swift-evolution@swift.org" class="m_-9049357509343812772m_8597572834478154638gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="m_-9049357509343812772m_8597572834478154638gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="m_-9049357509343812772m_8597572834478154638gmail_msg" target="_blank">https://lists.swift.org/mailma<wbr class="">n/listinfo/swift-evolution</a><br class="m_-9049357509343812772m_8597572834478154638gmail_msg"><br class="m_-9049357509343812772m_8597572834478154638gmail_msg"></blockquote></div></div></div></blockquote></div></div></blockquote></div><br class=""></div></div>______________________________<wbr class="">_________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailma<wbr class="">n/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></div><br class="">______________________________<wbr class="">_________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailma<wbr class="">n/listinfo/swift-evolution</a></blockquote></div></div></div></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></div>
</div></blockquote></div><br class=""></div></body></html>