<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">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="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 class="">>> 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 class="HOEnZb"><font color="#888888"><br>
--<br>
Brent Royal-Gordon<br>
Architechies<br>
</font></span><div class="HOEnZb"><div class="h5"><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>
</div></div></blockquote></div><br></div>