[swift-evolution] Remove Failable Initializers
Brent Royal-Gordon
brent at architechies.com
Thu Mar 3 16:27:14 CST 2016
>> 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.
>
> 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).
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".
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".
Forcing simple errors to use `throws` introduces a lot more complexity for no apparent benefit.
--
Brent Royal-Gordon
Architechies
More information about the swift-evolution
mailing list