[swift-evolution] Remove Failable Initializers

[Patrick Pijnappel]

The error handdling model as described in
https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst#kinds-of-error
is
very sensible and consistently applied throughout the language.

Returning an optional is a simplified form of returning an error when there
is only one straightforward way of failing. This is a very common case and
is simpler than using an error, for which you need to: 1) call
w/ try? 2) add 'throws' to the function 3) return some kind of error
instance of some type

On Thursday, 3 March 2016, David Hart via swift-evolution <
swift-evolution at swift.org> wrote:

> The reasoning for me is that they help describe the difference between a
> function that can return a nil value as part of it's normal operation and a
> function that can encounter an unexpected error.
>
> On 03 Mar 2016, at 00:44, Ross O'Brien via swift-evolution <
> swift-evolution at swift.org
> <javascript:_e(%7B%7D,'cvml','swift-evolution at swift.org');>> wrote:
>
> At the risk of appearing glib or naive - which isn't my intention, I'd
> like to know the answer - is there not a similar argument to be made for
> any function which returns an optional instead of throwing a more
> descriptive error? Asking an array for its first element returns an
> optional because of the possibility it might have no elements in it; should
> this throw an error instead of being 'failable'?
>
> On Wed, Mar 2, 2016 at 11:35 PM, Haravikk via swift-evolution <
> swift-evolution at swift.org
> <javascript:_e(%7B%7D,'cvml','swift-evolution at swift.org');>> wrote:
>
>>
>> On 2 Mar 2016, at 23:07, Chris Lattner via swift-evolution <
>> swift-evolution at swift.org
>> <javascript:_e(%7B%7D,'cvml','swift-evolution at swift.org');>> wrote:
>>
>> On Mar 2, 2016, at 1:11 PM, James Campbell via swift-evolution <
>> swift-evolution at swift.org
>> <javascript:_e(%7B%7D,'cvml','swift-evolution at swift.org');>> wrote:
>>
>>
>> Given that we now have error handling and availability checks does it
>> make sense to have Failable Initializers which date back to Swift 1.1?
>>
>>
>> Our error handling schema (
>> https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst#kinds-of-error)
>> defines how error conditions are handled, and one important class of them
>> (e.g. the "string to int" case) is best modeled as returning an optional.
>> This works really well in practice for functions/methods in general.
>>
>>
>> Could you give an example of why failable is the better fit here? To me
>> the following two statements are identical:
>>
>> let a = FailableType()
>> let b = try? ThrowableType()
>>
>> Except that in the latter case the try? is more explicit about what is
>> happening (and that it can fail), and I have the option of catching the
>> error to find out more about what went wrong. With some optimisation it
>> should be possible for try? to be just as efficient as a failable
>> initialiser I think.
>>
>> That said, the failable initialiser could have the same explicit call
>> syntax if it required a trailing question-mark, e.g:
>>
>> let a = FailableType()?
>>
>> As currently the only indicator is on the initialiser declaration itself.
>> Still, when it comes to debugging I’ve found it very useful to force myself
>> to use error handling instead, as it means I have to give reasons for why
>> something failed, which can make it easier to track issues when they do
>> arise.
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> <javascript:_e(%7B%7D,'cvml','swift-evolution at swift.org');>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> <javascript:_e(%7B%7D,'cvml','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/20160303/3e11e2b0/attachment.html>