I like to imagine "throws -> returnType" like a special tuple<br><br>let t = (e: NSError?, r: returnType)<br><br>Where "try" is a special function that accepts a tuple argument; a success closure; and one or more error blocks<br><br>func try(<br> _ t: (e: NSError?, r: returnType)<br> , do: ()->()<br> , catch: ((Error)->())...<br>) <br><br>So you could think of it as modifying the return type.<br><div class="gmail_quote"><div dir="ltr">On Mon, Dec 26, 2016 at 8:19 PM Daniel Leping via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_msg">IMO, considering "throws" is a modifier of function/method and determines how the function can be called (another good example is mutating) the logical approach would be to make things consistent and move everything either to the beginning or to the end of declaration.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">As long as "throws" is the only modifier at the end it's very logical to move it to the beginning and rename to "throwing". It feels like "throws" at the end is rather a legacy, probably from other languages and was a _default_ way of thinking at the time of initial implementation.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">I personally can live with both, though for the sake of consistency it should be moved to the beginning.</div><div class="gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">On Tue, 27 Dec 2016 at 6:00 thislooksfun via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg">As far as I know, `throws` only affects whether or not the code must be marked with a `try` statement, the actual return type/value is unchanged (since it would be unreached if an error was thrown).<br class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><div style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word" class="gmail_msg"><br class="gmail_msg">-thislooksfun (tlf)</div><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"></div></div><div style="word-wrap:break-word" class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Dec 26, 2016, at 1:18 PM, David Sweeris <<a href="mailto:davesweeris@mac.com" class="gmail_msg" target="_blank">davesweeris@mac.com</a>> wrote:</div><br class="m_-4754906039739136605m_4996534704032090138Apple-interchange-newline gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">On Dec 26, 2016, at 09:38, thislooksfun via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg"><br class="gmail_msg"></div><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">Hello Swifters,<div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">I've been writing a lot more Swift code recently, and I have found that the default placement of the 'throws' declaration is often confusing, especially to those of us switching from languages where the type of errors thrown is explicitly defined (like Java)</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">For example,</div><div class="gmail_msg"><div class="m_-4754906039739136605m_4996534704032090138bloop_markdown gmail_msg" style="font-family:Helvetica,Arial;font-size:13px;background-color:rgb(254,254,254)"><pre style="margin-top:15px;margin-bottom:15px;font-family:Menlo,Consolas,'Liberation Mono',Courier,monospace;font-size:10pt;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;background-color:rgb(248,248,248);color:inherit;border:1px solid rgb(204,204,204);overflow:auto;padding:4px 8px;word-break:normal;word-wrap:normal" class="gmail_msg">// This is pretty clear, this can throw an error<br class="gmail_msg"><br class="gmail_msg">func foo() throws<br class="gmail_msg"><br class="gmail_msg">{ ... }<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">// Also pretty clear, this returns a String<br class="gmail_msg"><br class="gmail_msg">func bar() -> String<br class="gmail_msg"><br class="gmail_msg">{ ... }<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">// Confusing. Does this throw a String? Does it return a String? Does it do both?<br class="gmail_msg"><br class="gmail_msg">// I personally keep reading this as 'this can throw a String'<br class="gmail_msg"><br class="gmail_msg">func baz() throws -> String<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">// Equivalent code in Java (not a model, just for clarification of why the above is confusing)<br class="gmail_msg"><br class="gmail_msg">String baz() throws StringFormatException</pre></div><div class="gmail_msg">I therefore suggest either tweaking the syntax around, or moving, the `throws` keyword to avoid this confusion.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Some ideas I've had:</div><div class="gmail_msg"><pre style="color:inherit;margin-top:15px;margin-bottom:15px;font-family:Menlo,Consolas,'Liberation Mono',Courier,monospace;font-size:10pt;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;background-color:rgb(248,248,248);border:1px solid rgb(204,204,204);overflow:auto;padding:4px 8px;word-break:normal;word-wrap:normal" class="gmail_msg">// Add a comma to separate them<br class="gmail_msg"><br class="gmail_msg">func baz() throws, -> String<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">// Move `throws` to the end<br class="gmail_msg"><br class="gmail_msg">func baz() -> String throws<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">// Change it to a prefix modifier (like `mutating`)<br class="gmail_msg"><br class="gmail_msg">throwing func baz() -> String<br class="gmail_msg"><br class="gmail_msg"></pre></div><div class="gmail_msg">I'm still not sold on any of the above syntaxes, but I would love to hear your feedback.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">This would affect existing code, but it would be a fairly small change that would result in very large readability improvements, especially for newcomers, and <i class="gmail_msg">especially</i> for those coming for a language such as Java.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><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="gmail_msg">-thislooksfun (tlf)</div></div></div></div></blockquote><br class="gmail_msg"><div class="gmail_msg">Does `throws` affect the actual return type? That is, is the size of the returned data different between "func foo() -> Int8" and "func foo() throws -> Int8"? If so, the "throws" is quite literally part of the return type and the current syntax reflects that. If not, I <i class="gmail_msg">think</i> I'd probably be in favor of that last "prefix modifier" suggestion with either "throwing" or "@throwing" (depending on the exact semantics of the "@" part — I'm a bit unclear on that detail)... probably... maybe... I'll have to think about it some more.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">- Dave Sweeris</div><div class="gmail_msg"><br class="gmail_msg"></div></div></div></blockquote></div><br class="gmail_msg"></div>_______________________________________________<br class="gmail_msg"><br class="gmail_msg">swift-evolution mailing list<br class="gmail_msg"><br class="gmail_msg"><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg"><br class="gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg"><br class="gmail_msg"></blockquote></div></div>
_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div>