[swift-evolution] Remove Failable Initializers

[Ross O'Brien]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160302/b1d292d9/attachment.html>