<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="">+1 from me. I’m usually highly defensive about types, so the more the compiler can guarantee the better. <div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 26, 2016, at 9:01 AM, Nur Ismail via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><font face="Helvetica" class="">Hi,</font><div class=""><font face="Helvetica" class=""><br class=""></font></div><div class=""><font face="Helvetica" class="">Sounds like checked exceptions of Java with a similar syntax. With Java you have to specify the exceptions a method can throw. However been lots of debate over the years whether it's a good thing or bad thing, some like it, but I think many more hate it.</font></div></div></div></blockquote><div><br class=""></div>I’m pretty sure what people don’t like in Java is the enforced error handling or propagation and how much you have to nest to, e.g. set up IO, though I believe that has been mitigated somewhat by try-with-resources), not the specificity (and how it’s not obvious to many which throws need to be caught at compile time and which are RuntimeExceptions). Though I don’t write much Java nowadays, I know I never liked all the boilerplate that required.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><font face="Helvetica" class="">Most other languages don't have it, and possibly for good reason.</font></div></div></div></blockquote><div><br class=""></div>I’d love to hear those arguments against letting the compiler make more guarantees.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><font face="Helvetica" class=""><br class=""></font></div><div class=""><font face="Helvetica" class="">Regards,</font></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Aug 26, 2016 at 5:43 PM, Rod Brown via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><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=""><div class=""><div class="">(resent for Swift Evolution)</div><div class=""><br class=""></div><div class="">I’m a big fan of this idea. Currently “throws” seems like a very limited API - you know it’s throwing out something, but you can only hope to guess what that is or create fallbacks. Definitely a big +1 from me. A fallback for compatibility could be “throws” assumes “throws Any” and can be a warning?</div></div></div></blockquote></div></div></div></blockquote><div><br class=""></div><div>I’d suggest a bare `throws` = `throws ErrorType` (you can only throw ErrorType, right?) and be valid, I don’t see any reason to make it a warning (plus that keeps source compatibility). </div><br class=""><blockquote type="cite" class=""><div 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=""><div class=""><div class=""><br class=""></div><div class="">While I am not deeply familiar with the implications, I do like think your line of reasoning has merit, and think this makes sense for Phase 1 of Swift 4. </div><div class=""><br class=""></div><div class="">- Rod</div></div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class=""><div class="h5"><div class="">On 27 Aug 2016, at 1:39 AM, Félix Cloutier via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class=""></div></div><div class=""><div class=""><div class="h5"><div style="word-wrap:break-word" class="">Hi all,<div class=""><br class=""></div><div class="">Currently, a function that throws is assumed to throw anything. There was a proposal draft last December to restrict that. The general idea was that you'd write, for instance:</div><div class=""><br class=""></div><div class=""></div><blockquote type="cite" class=""><div class="">enum Foo: ErrorProtocol {</div><div class=""> case bar</div><div class=""> case baz</div><div class="">}</div><div class=""><br class=""></div><div class="">func frob() throws Foo {</div><div class=""> throw Foo.bar // throw .bar?</div><div class="">}<br class=""></div></blockquote><div class=""><br class=""></div>If you `catch Foo` (or every case of Foo), now that the compiler can verify that your catch is exhaustive, you no longer have to have a catch-all block at the end of the sequence.<br class=""><div class=""><br class=""></div>This impacts the metadata format and has implications on resilience, which leads me to believe that the discussion could qualify for the phase 1 of Swift 4. If this is the case, I'd be interested in pulling out the old discussions and seeing where we left that at.<br class=""><div class=""><div class="">
<br class=""><span style="font-family:'Lucida Grande';font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">Félix</span>
</div>
<br class=""></div></div></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/<wbr class="">mailman/listinfo/swift-<wbr class="">evolution</a><br class=""></div></blockquote></div><br class=""></div><br class="">______________________________<wbr class="">_________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" 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/<wbr class="">mailman/listinfo/swift-<wbr class="">evolution</a><br class="">
<br class=""></blockquote></div><br class=""></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>