<div dir="ltr">I'm going to write up a formal proposal, at the very least perhaps the documentation everyone is linking to could be made a formal part of the API Guidelines on how to handle returning errors.</div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">
<p><b><font color="#cc0000">___________________________________</font></b></p><p><b>James⎥Head of Trolls</b></p><p><b><font color="#cc0000"><a href="mailto:james@supmenow.com" target="_blank">james@supmenow.com</a>⎥<a href="http://supmenow.com" target="_blank">supmenow.com</a></font></b></p><p><b><font size="2">Sup</font></b></p><p><b><font size="2">Runway East
</font></b></p><p><b><font size="2">10 Finsbury Square</font></b></p><p><b><font size="2">London</font></b></p><p><b><font size="2">
EC2A 1AF </font></b></p></div></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Fri, Mar 4, 2016 at 11:13 AM, Andrew Bennett via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I prefer `<font face="monospace, monospace">try? Int(someString)</font>` over `<font face="monospace, monospace">Int(someString)</font>`.<div><ul><li>There's visually nothing to indicate that `<font face="monospace, monospace">Int(someString)</font>` could fail.</li><li>It simplifies the language to not have failable initialisers.</li></ul><div>InvalidArgument could be part of the standard library, something like this: </div><div><br></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div><font face="monospace, monospace">struct InvalidArgument: ErrorType {</font><span style="font-family:monospace,monospace">}</span></div></div></blockquote><div><div><div><br></div><div>Brent makes a good point:</div></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div><div>"<span style="font-size:13px">40 bytes for a protocol witness, instead of 0-1 bytes for the overhead of an Optional</span>".</div></div></div></blockquote><div><div><br></div><div>I wonder if it a typed throw would have similar overhead to an optional, possibly less if the throw only has an overhead if it is <a href="http://llvm.org/docs/ExceptionHandling.html#itanium-abi-zero-cost-exception-handling" target="_blank">thrown</a>:</div></div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div><font face="monospace, monospace">init (_ fromString: String) throws(InvalidArgument)</font></div></div></blockquote><font face="monospace, monospace"><br></font><div><div>I don't know what happened to the proposal to allow throws to specify zero or one type. I'm reluctant to use throws in general without that proposal.</div><div><br></div></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 4, 2016 at 9:27 AM, Brent Royal-Gordon via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>>> The guidance is that returning nil is appropriate when your function could fail due to simple domain errors, for instance passing a negative value as a parameter where they aren't allowed.<br>
><br>
> If that’s all you need then what’s wrong with throwing some generic purpose illegal argument type exception and using try? It’s functionally the same, i.e- removing failable initialisers doesn’t actually remove a capability, it just removes what is essentially now a redundant one. In other words, try? on a throwable initialiser is now functionally identical to a failable initialiser and isn't appreciably more complex, especially if there’s a common exception that can be thrown for general purpose invalid argument errors (not sure if there is one right now, but it could be added to the proposal).<br>
<br>
</span>If there's a "general purpose invalid argument error", then that error is not communicating anything more than an optional would. It's merely taking a lot more syntax on both sides of the call, plus complexity in the calling convention and space in memory (40 bytes for a protocol witness, instead of 0-1 bytes for the overhead of an Optional!), to convey the same single bit of information: "Your data was wrong".<br>
<br>
And if there isn't a general-purpose error, you're adding even *more* syntax and complexity—an entire new type to conform to ErrorType—and once again only conveying the same single bit of information: "Your data was wrong".<br>
<br>
Forcing simple errors to use `throws` introduces a lot more complexity for no apparent benefit.<br>
<span><font color="#888888"><br>
--<br>
Brent Royal-Gordon<br>
Architechies<br>
</font></span><div><div><br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div>