Re: [swift-evolution] Failable Initializer Suggestion

[Dennis Lysenko via swift-evolution]

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@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@swift.org>:
>
> On Dec 27, 2015, at 5:22 AM, Manfred Lau via swift-evolution <
> swift-evolution@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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Failable Initializer Suggestion

[Thorsten Seitz via swift-evolution]

+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 
> :
> 
>> On Dec 27, 2015, at 5:22 AM, Manfred Lau via swift-evolution 
>>  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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Failable Initializer Suggestion

[Tino Heth via swift-evolution]

> How do you guys think of that?
Makes sense.
Failable init has its roots in Objective-C, throws is a better fit for Swift — 
but it is not trivial to change all Cocoa class to throw instead of returning 
nil (at least in theory — most likely many classes don't have that many reasons 
for a possible error).
Imho failable init should be removed again (but in a timeframe beyond the 
normal range of this list ;-)

Tino___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution