[swift-evolution] Remove Failable Initializers

[James Campbell]

To me it depends on if the function returns a value or the result of an
action which may have different results not related to the value.

- The first function on an array returns a value, the first item in an
array. In this case an optional makes sense as its easy to handle by
returning nil since there is no value that exists at index(1)
- The subscript operator could return an optional too when we are out of
bounds since the value doesn't exist.
- Having a init throw an error makes sense to me, as for complex structures
and classes there are many reasons it can fail, its not that simple to say
there wasn't a value (was there some internal validation that failed)
- A fetch operation for a network request would throw on the same princible
(i.e was networking down?)
- However a function that just calculated a value lets say the next URL for
the next page in a eBook, would probably want too return nil since all its
doing is returning a value (i.e there is a next page for this book).

*___________________________________*

*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 Wed, Mar 2, 2016 at 11:44 PM, Ross O'Brien via swift-evolution <
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> wrote:
>
>>
>> On 2 Mar 2016, at 23:07, Chris Lattner via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> On Mar 2, 2016, at 1:11 PM, James Campbell via swift-evolution <
>> 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
>> 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/20160302/80837ada/attachment.html>