[swift-evolution] Remove Failable Initializers

[James Campbell]

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.

*___________________________________*

*James⎥Head of Trolls*

*james at supmenow.com <james at supmenow.com>⎥supmenow.com <http://supmenow.com>*

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On Fri, Mar 4, 2016 at 11:13 AM, Andrew Bennett via swift-evolution <
swift-evolution at swift.org> wrote:

> 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
>>
>
>
> _______________________________________________
> 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/3709f120/attachment.html>