<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="">Jens -<div class=""><br class=""></div><div class="">I apologize for having annoyed you, but this thread has been very informative for me.<div class=""><br class=""></div><div class="">I was under the misconception that Swift was more similar to Java and .NET than to C, C++ and Obj-C. Your statement - <b class="">The designers of Swift do not like exceptions.</b> - clears up some of my misunderstanding of fundamental principles guiding Swift design. And thank you Brent Royal-Gordon - your explanation was of great help in furthering my understanding of those design decisions.</div><div class=""><br class=""></div><div class="">I was seriously considering moving toward the use of Swift as <i class="">the</i> programming language of the future for my companies' mission-critical business application systems, but the knowledge I've gained in this thread has disabused me of that.</div><div class=""><br class=""></div><div class="">Sincerely,</div><div class="">Don Wills</div><div class="">owner, Produce Pro, Inc. and Portable Software Company<br class=""><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 8, 2016, at 10:55 PM, Jens Alfke <<a href="mailto:jens@mooseyard.com" class="">jens@mooseyard.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><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 class=""><br class=""></div><div class="">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 class=""><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 class="">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 class=""><br class=""></div><div class=""><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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">—Jens</div></div></div></blockquote></div><br class=""></div></div></div></body></html>