[swift-evolution] Remove Failable Initializers

[Andrew Bennett]

I prefer `try? Int(someString)` over `Int(someString)`.

   - There's visually nothing to indicate that `Int(someString)` could fail.
   - It simplifies the language to not have failable initialisers.

InvalidArgument could be part of the standard library, something like this:

struct InvalidArgument: ErrorType {}


Brent makes a good point:

"40 bytes for a protocol witness, instead of 0-1 bytes for the overhead of
an Optional".


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 thrown
<http://llvm.org/docs/ExceptionHandling.html#itanium-abi-zero-cost-exception-handling>
:

init (_ fromString: String) throws(InvalidArgument)


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.


On Fri, Mar 4, 2016 at 9:27 AM, Brent Royal-Gordon via swift-evolution <
swift-evolution at swift.org> wrote:

> >> 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
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160304/705412d0/attachment.html>