[swift-evolution] Remove Failable Initializers

David Owens II david at owensd.io
Wed Mar 9 12:10:32 CST 2016

So you would you be happy if failable inits were declared like this:

init() -> self? {}

Unfortunately, Swift decided to make init() a special case thing. It's also the only function type that has special rules around accessing properties, the only one that cannot be named differently, the only one that has special rules around recursing or forwarding to other init() calls, and many other special rules and considerations. 

The ability to use optionals is one of the key components to Swift's error handling story. Why should initializers not be able to participate in that story? I don't agree with your consistency argument; init() is already completely inconsistent from every other function in Swift. It's a side-effect of all of the other choices around init() that cause the inconsistent syntax with other functions signatures.


> On Mar 9, 2016, at 9:20 AM, Tino Heth via swift-evolution <swift-evolution at swift.org> wrote:
>> let i: Int = Int.init(123)
>> would not compile if that initializer had a return type of Void rather than Int.
> No one can argue the observation that init-methods have return values (although I think it's rather uncommon to invoke them that way) — but that is not my point:
> Let's imagine I write a library with a numeric type, and define the "+"-operator to perform a multiplication.
> Given this,
> let x: StringIntLiteralConvertible = 2 + 5
> should assign x a value of 10: That is how the operation is defined (like "init" is defined to return self), and according to your argumentation, everything is fine.
> Nonetheless, I'd say this operator is inconsistent, because it contradicts to common behavior, and "+" should be linked to addition.
> Initializers behave similar (on another level, though):
> They have the signature of a void function, they have the body of a void function — but yet they return something.
> You are right that this is actually a topic on its own, as "init?" just emphasizes the "oddity", because suddenly there is a need to manually add a return statement for one case...
> Tino
> _______________________________________________
> 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/20160309/b4e9674a/attachment.html>

More information about the swift-evolution mailing list