I thought there is already a pending proposal on typed throws?<br><div class="gmail_quote"><div dir="ltr">On Wed, Dec 28, 2016 at 22:34 thislooksfun 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 style="word-wrap:break-word" class="gmail_msg">+1 for optional type definition. As someone also coming from Java, I agree that its implementation is less than ideal. When I first suggested moving the `throws` statement, I thought the decision on whether or not to declare (even optionally) the exception types had already been made. I see now that I was mistaken.<div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">It seems clear that the two issues are closely tied, and the decision on moving the `throws` statement can't be made until a decision on type defined errors is made.</div><div class="gmail_msg">For that reason, perhaps this should now move to a new thread discussing how best to implement a(n optional) typed `throws` system?<br class="gmail_msg"><div 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>
</div></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg">
<br class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Dec 28, 2016, at 3:59 PM, Christopher Kornher via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_8213086070347842391Apple-interchange-newline gmail_msg"><div class="gmail_msg"><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg">-1 for addressing this now. Typed throws will undoubtedly affect this change and the two issues should be addressed at the same time.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">As a Java veteran, I agree with the sentiment to avoid the Java exception typing mechanism which complicates using and maintaining large projects. Knowing the recoverable exceptions that a function can throw cane be useful, however, and some sort of optional listing of exception types is probably the best solution.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Dec 28, 2016, at 2:36 PM, Anton Zhilin via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_8213086070347842391Apple-interchange-newline gmail_msg"><div class="gmail_msg"><div dir="ltr" class="gmail_msg"><div class="m_8213086070347842391markdown-here-wrapper gmail_msg"><p style="margin:0px 0px 1.2em!important" class="gmail_msg">TLDR: I support moving <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline" class="gmail_msg">throws</code>, and also think that ‘typed throws’ should fit for Phase 2, at least.</p>
<blockquote style="margin:1.2em 0px;border-left:4px solid rgb(221,221,221);padding:0px 1em;color:rgb(119,119,119);quotes:none" class="gmail_msg">
<pre style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;font-size:1em;line-height:1.2em;margin:1.2em 0px" class="gmail_msg"><code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline;white-space:pre-wrap;overflow:auto;border-radius:3px;border:1px solid rgb(204,204,204);padding:0.5em 0.7em;display:block!important" class="gmail_msg">let x : (_ a : Int) -> (_ b: Float) throws -> Double throws
</code></pre></blockquote><p style="margin:0px 0px 1.2em!important" class="gmail_msg">Count me in those who cried in anger :)</p>
<hr class="gmail_msg"><p style="margin:0px 0px 1.2em!important" class="gmail_msg">I see why current syntax is very logical for currying:</p>
<pre style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;font-size:1em;line-height:1.2em;margin:1.2em 0px" class="gmail_msg"><code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline;white-space:pre-wrap;overflow:auto;border-radius:3px;border:1px solid rgb(204,204,204);padding:0.5em 0.7em;display:block!important" class="gmail_msg">let x: (Int) throws -> (Float) throws -> Double // clean
let x: (Int) -> (Float) -> Double throws throws // looks ambiguous
</code></pre><p style="margin:0px 0px 1.2em!important" class="gmail_msg">Although, the ambiguity can be resolved using parentheses:</p>
<pre style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;font-size:1em;line-height:1.2em;margin:1.2em 0px" class="gmail_msg"><code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline;white-space:pre-wrap;overflow:auto;border-radius:3px;border:1px solid rgb(204,204,204);padding:0.5em 0.7em;display:block!important" class="gmail_msg">let x: (Int) -> ((Float) -> Double throws) throws
let x: (Int) -> ((Float) -> Double throws Error2) throws Error1 // with 'typed throws'
</code></pre><p style="margin:0px 0px 1.2em!important" class="gmail_msg">Compare it to how we incorporate optionals (which are just another form of error handling) in curried functions now:</p>
<pre style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;font-size:1em;line-height:1.2em;margin:1.2em 0px" class="gmail_msg"><code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline;white-space:pre-wrap;overflow:auto;border-radius:3px;border:1px solid rgb(204,204,204);padding:0.5em 0.7em;display:block!important" class="gmail_msg">let x: (Int) -> ((Float) -> Double?)?
</code></pre><p style="margin:0px 0px 1.2em!important" class="gmail_msg">Overall, current Swift syntax is uniquely nice to error handling in curried functions. Is it worth keeping this advantage? Probably not, if the new form does not contain too much noise and is even more logical. Everything slides into place, if <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline" class="gmail_msg">throws</code> is a binary operator on types with precedence higher than <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline" class="gmail_msg">-></code>. Although <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline" class="gmail_msg">A throws B</code> is not a type on itself, I can clearly see it becoming one in the future. Then <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline" class="gmail_msg">try</code> will handle pattern matching of such types.</p><p style="margin:0px 0px 1.2em!important" class="gmail_msg">Another point for the suggested syntax: as we now know, Swift users prefer to see results after <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline" class="gmail_msg">-></code> in function declarations. Is it stretching too far to conclude that error type is a possible result, and should also come after <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline" class="gmail_msg">-></code>?</p>
<div title="MDH:PGRpdj5UTERSOiBJIHN1cHBvcnQgbW92aW5nIGB0aHJvd3NgLCBhbmQgYWxzbyB0aGluayB0aGF0
ICd0eXBlZCB0aHJvd3MnIHNob3VsZCBmaXQgZm9yIFBoYXNlIDIsIGF0IGxlYXN0Ljxicj48L2Rp
dj48ZGl2Pjxicj48L2Rpdj48ZGl2PiZndDsgYGBgPC9kaXY+PGRpdj4mZ3Q7IGxldCB4IDogKF8g
YSA6IEludCkgLSZndDsgKF8gYjogRmxvYXQpIHRocm93cyAtJmd0OyBEb3VibGUgdGhyb3dzPGJy
PjwvZGl2PjxkaXY+Jmd0OyBgYGA8L2Rpdj48ZGl2Pjxicj48L2Rpdj5Db3VudCBtZSBpbiB0aG9z
ZSB3aG8gY3JpZWQgaW4gYW5nZXIgOik8ZGl2Pjxicj48L2Rpdj48ZGl2PjxkaXY+LS0tPGJyPjxk
aXY+PGJyPjxkaXY+SSBzZWUgd2h5IGN1cnJlbnQgc3ludGF4IGlzIHZlcnkgbG9naWNhbCBmb3Ig
Y3Vycnlpbmc6PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5gYGA8L2Rpdj48ZGl2PmxldCB4OiAo
SW50KSB0aHJvd3MgLSZndDsgKEZsb2F0KSB0aHJvd3MgLSZndDsgRG91YmxlICZuYnNwOyAvLyBj
bGVhbjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+bGV0IHg6IChJbnQpIC0mZ3Q7IChGbG9hdCkg
LSZndDsgRG91YmxlIHRocm93cyB0aHJvd3MgJm5ic3A7IC8vIGxvb2tzIGFtYmlndW91czwvZGl2
PjxkaXY+YGBgPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5BbHRob3VnaCwgdGhlIGFtYmlndWl0
eSBjYW4gYmUgcmVzb2x2ZWQgdXNpbmcgcGFyZW50aGVzZXM6PC9kaXY+PGRpdj48YnI+PC9kaXY+
PGRpdj5gYGA8L2Rpdj48ZGl2PmxldCB4OiAoSW50KSAtJmd0OyAoKEZsb2F0KSAtJmd0OyBEb3Vi
bGUgdGhyb3dzKSB0aHJvd3M8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PmxldCB4OiAoSW50KSAt
Jmd0OyAoKEZsb2F0KSAtJmd0OyBEb3VibGUgdGhyb3dzIEVycm9yMikgdGhyb3dzIEVycm9yMSAm
bmJzcDsgLy8gd2l0aCAndHlwZWQgdGhyb3dzJzxicj48L2Rpdj48ZGl2PmBgYDwvZGl2PjxkaXY+
PGJyPjwvZGl2PjxkaXY+Q29tcGFyZSBpdCB0byBob3cgd2UgaW5jb3Jwb3JhdGUgb3B0aW9uYWxz
ICh3aGljaCBhcmUganVzdCBhbm90aGVyIGZvcm0gb2YgZXJyb3IgaGFuZGxpbmcpIGluIGN1cnJp
ZWQgZnVuY3Rpb25zIG5vdzo8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PmBgYDwvZGl2PjxkaXY+
bGV0IHg6IChJbnQpIC0mZ3Q7ICgoRmxvYXQpIC0mZ3Q7IERvdWJsZT8pPzwvZGl2PjxkaXY+YGBg
PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5PdmVyYWxsLCBjdXJyZW50IFN3aWZ0IHN5bnRheCBp
cyB1bmlxdWVseSBuaWNlIHRvIGVycm9yIGhhbmRsaW5nIGluIGN1cnJpZWQgZnVuY3Rpb25zLiBJ
cyBpdCB3b3J0aCBrZWVwaW5nIHRoaXMgYWR2YW50YWdlPyBQcm9iYWJseSBub3QsIGlmIHRoZSBu
ZXcgZm9ybSBkb2VzIG5vdCBjb250YWluIHRvbyBtdWNoIG5vaXNlIGFuZCBpcyBldmVuIG1vcmUg
bG9naWNhbC4gRXZlcnl0aGluZyBzbGlkZXMgaW50byBwbGFjZSwgaWYgYHRocm93c2AgaXMgYSBi
aW5hcnkgb3BlcmF0b3Igb24gdHlwZXMgd2l0aCBwcmVjZWRlbmNlIGhpZ2hlciB0aGFuIGAtJmd0
O2AuIEFsdGhvdWdoIGBBIHRocm93cyBCYCBpcyBub3QgYSB0eXBlIG9uIGl0c2VsZiwgSSBjYW4g
Y2xlYXJseSBzZWUgaXQgYmVjb21pbmcgb25lIGluIHRoZSBmdXR1cmUuIFRoZW4gYHRyeWAgd2ls
bCBoYW5kbGUgcGF0dGVybiBtYXRjaGluZyBvZiBzdWNoIHR5cGVzLjwvZGl2PjxkaXY+PGJyPjwv
ZGl2PjxkaXY+QW5vdGhlciBwb2ludCBmb3IgdGhlIHN1Z2dlc3RlZCBzeW50YXg6IGFzIHdlIG5v
dyBrbm93LCBTd2lmdCB1c2VycyBwcmVmZXIgdG8gc2VlIHJlc3VsdHMgYWZ0ZXIgYC0mZ3Q7YCBp
biBmdW5jdGlvbiBkZWNsYXJhdGlvbnMuIElzIGl0IHN0cmV0Y2hpbmcgdG9vIGZhciB0byBjb25j
bHVkZSB0aGF0IGVycm9yIHR5cGUgaXMgYSBwb3NzaWJsZSByZXN1bHQsIGFuZCBzaG91bGQgYWxz
byBjb21lIGFmdGVyIGAtJmd0O2A/PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+" style="height:0;width:0;max-height:0;max-width:0;overflow:hidden;font-size:0em;padding:0;margin:0" class="gmail_msg"></div></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" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg"></div></blockquote></div><br class="gmail_msg"></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" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg"></div></blockquote></div><br class="gmail_msg"></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>