<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 Jan 8, 2016, at 6:38 PM, Don Wills <<a href="mailto:don.wills@portablesoftware.com" class="">don.wills@portablesoftware.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="font-family: Alegreya-Regular; font-size: 15px; 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; float: none; display: inline !important;" class="">All I am asking for is that the "throws" keyword on a method definition be optional - that is, a method can throw a <thingy> with the throw statement without specifying "throws", and it can be caught by a matching try/catch clause up the stack.</span></div></blockquote><div><br class=""></div><div>That’s asking for much, much, much more than making a keyword optional. You’re asking for the underlying error handling mechanism to be something completely different than what it is, i.e. stack-unwinding exceptions rather than returning an error value.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><span style="font-family: Alegreya-Regular; font-size: 15px; 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; float: none; display: inline !important;" class="">That is perfectly possible with LLVM and does not entail any ill-defined behavior. </span></div></blockquote><br class=""></div><div>There is a <i class="">vast</i> difference between machine code supporting something, and a language supporting it. You could say the same thing about nearly any language feature that Swift decided not to support. “But LLVM allows multiple inheritance!” “There’s nothing in LLVM preventing making all value bindings immutable!” “LLVM supports goto statements!"</div><div><br class=""></div><div><b class="">The designers of Swift do not like exceptions.</b> They decided not to include them in the language. Arguing for exceptions here is a tiresome religious war. When I worked at Apple I had some arguments about exceptions with people on the Cocoa and compiler teams. I definitely prefer exceptions to plain old return values (as in C or Go or Swift 1.x), but the compromise in Swift 2 is good enough that I’m happy with it, and I appreciate arguments like Brent’s about the overhead it saves. (If you’ve looked t the disassembly of exception-heavy C++ code, you can see all the code-size overhead it adds.)</div><div><br class=""></div><div>All language designers have features they dislike and won’t add. Try arguing for late-binding dynamic dispatch to C++ gurus. Try arguing for explicit “free” calls in a Java forum. Tell the Haskell maintainers that mutable variables make coding so much easier. If you think language designers should give in and add every feature someone thinks is important, <i class="">then</i> you get the real kitchen sink you keep saying Swift is.</div><div><br class=""></div><div>That’s the last I’m going to write about this. It’s stopped having any value. I’ve been around long enough to be sick of language flame wars, and that’s about all this is.</div><div><br class=""></div><div>—Jens</div></body></html>