[swift-evolution] Failable Initializer Suggestion

[Dennis Lysenko]

My initial stance several months ago was that initializers should throw
instead of returning nil, but I've changed it as a result of the error
handling rationale (same document as Chris linked).

Specifically this section, taken from ErrorHandlingRationale.rst:

Simple domain errors

A simple domain error is something like calling String.toInt() on a string
that isn't an integer. The operation has an obvious precondition about its
arguments, but it's useful to be able to pass other values to test whether
they're okay. The client will often handle the error immediately.

Conditions like this are best modeled with an optional return value. They
don't benefit from a more complex error-handling model, and using one would
make common code unnecessarily awkward. For example, speculatively trying
to parse aString as an integer in Java requires catching an exception,
which is far more syntactically heavyweight (and inefficient without
optimization).

Because Swift already has good support for optionals, these conditions do
not need to be a focus of this proposal.

In constructors, the most common (and I would posit the only common) case
of error would be a simple domain error, so failable initializers suffice.

On Tue, Jan 5, 2016 at 12:52 AM Thorsten Seitz via swift-evolution <
swift-evolution at swift.org> wrote:

> +1 for keeping failable initializers. Error handling should be reserved
> for errors and not be used for control flow or logic.
>
> -Thorsten
>
> Am 27.12.2015 um 18:11 schrieb Chris Lattner via swift-evolution <
> swift-evolution at swift.org>:
>
> On Dec 27, 2015, at 5:22 AM, Manfred Lau via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> I just found that the design of failable initializer is redundant in Swift
> 2. Because native error handling already has been introduced in Swift 2,
> and failable initializer indeed could be achieved by following codes:
>
>
> I’d be opposed to removing failable initializers.  Failable inits
> introduce a symmetry into the language for initializers, which make them
> possible to do (almost) all of what you can do with a normal method.  This
> capability is key for them to be able to replace “factory” static methods,
> which allows Swift to offer a consistent initialization pattern for clients
> of types.
>
> If we forced people to use error handling for anything that could return
> nil, then things like String to Int conversions would most likely not use
> initialization syntax.
>
> Besides that, over use of error handling waters it down and makes it less
> valuable in itself.  For more information on this, please see the design
> discussion for error handling:
> https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst
>
> -Chris
>
> _______________________________________________
> 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/20160105/64cc04d7/attachment.html>