See the comments. Why is one allowed but the other one isn't and what's the rationale for this?
class Vehicle { let name: String init(name: String) { self.name = name }}
class Car: Vehicle { //Why is this not allowed? override init?(name: String) { super.init(name: name) } //But this is allowed? init?(name: String, ignore: String) { super.init(name: name) }}
You can’t override a designated initializer with one that is failable. The second one is defining a new initializer that is failable, instead of overriding the one from its superclass.
Saagar Jha
···
On Jan 27, 2017, at 8:45 AM, tuuranton--- via swift-users <swift-users@swift.org> wrote:
See the comments. Why is one allowed but the other one isn't and what's the rationale for this?
class Vehicle {
let name: String
init(name: String) {
self.name = name
}
}
class Car: Vehicle {
//Why is this not allowed?
override init?(name: String) {
super.init(name: name)
}
//But this is allowed?
init?(name: String, ignore: String) {
super.init(name: name)
}
}
Yes, but why?
What's the rationale for this?
What would be so bad about allowing overriding a non-failable initializer with a failable initializer?
27. Jan 2017 18:59 by saagar@saagarjha.com:
···
You can’t override a designated initializer with one that is failable. The second one is defining a new initializer that is failable, instead of overriding the one from its superclass.
Saagar Jha
On Jan 27, 2017, at 8:45 AM, tuuranton--- via swift-users <>> swift-users@swift.org>> > wrote:
>> See the comments. Why is one allowed but the other one isn't and what's the rationale for this?
class Vehicle {>> let name: String>> init(name: String) {>> self.name = name>> }>> }
class Car: Vehicle {>> //Why is this not allowed?>> override init?(name: String) {>> super.init(name: name)>> }>> >> //But this is allowed?>> init?(name: String, ignore: String) {>> super.init(name: name)>> }>> }
Convenience initializers are inherited when you override all of your parent class's designated initializers. If you change the signature of the designated initializer, then the convenience initializers will no longer do the right thing.
However, we could allow this case and just consider it shadowing the original initializer rather than overriding. In that case, though, we'd probably want something like @nonoverriding to make it clear that it was intentional.
Jordan
···
On Jan 27, 2017, at 10:39, tuuranton--- via swift-users <swift-users@swift.org> wrote:
Yes, but why?
What's the rationale for this?
What would be so bad about allowing overriding a non-failable initializer with a failable initializer?
27. Jan 2017 18:59 by saagar@saagarjha.com <mailto:saagar@saagarjha.com>:
You can’t override a designated initializer with one that is failable. The second one is defining a new initializer that is failable, instead of overriding the one from its superclass.
Saagar Jha
On Jan 27, 2017, at 8:45 AM, tuuranton--- via swift-users <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
See the comments. Why is one allowed but the other one isn't and what's the rationale for this?
class Vehicle {
let name: String
init(name: String) {
self.name = name
}
}
class Car: Vehicle {
//Why is this not allowed?
override init?(name: String) {
super.init(name: name)
}
//But this is allowed?
init?(name: String, ignore: String) {
super.init(name: name)
}
}
What would be so bad about allowing overriding a non-failable initializer with a failable initializer?
If the non-failable initializer witnesses a non-failable protocol requirement, and the subclass overrides it, what should be the runtime behavior if the subclass initializer returns nil? The caller won’t expect it, since the caller is calling a non-failable initializer.
For similar reasons, you cannot override a method that returns a non-optional value with a method returning an optional value.
Slava
···
On Jan 27, 2017, at 10:39 AM, tuuranton--- via swift-users <swift-users@swift.org> wrote:
27. Jan 2017 18:59 by saagar@saagarjha.com <mailto:saagar@saagarjha.com>:
You can’t override a designated initializer with one that is failable. The second one is defining a new initializer that is failable, instead of overriding the one from its superclass.
Saagar Jha
On Jan 27, 2017, at 8:45 AM, tuuranton--- via swift-users <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
See the comments. Why is one allowed but the other one isn't and what's the rationale for this?
class Vehicle {
let name: String
init(name: String) {
self.name = name
}
}
class Car: Vehicle {
//Why is this not allowed?
override init?(name: String) {
super.init(name: name)
}
//But this is allowed?
init?(name: String, ignore: String) {
super.init(name: name)
}
}
What would be so bad about allowing overriding a non-failable initializer with a failable initializer?
If the non-failable initializer witnesses a non-failable protocol requirement, and the subclass overrides it, what should be the runtime behavior if the subclass initializer returns nil? The caller won’t expect it, since the caller is calling a non-failable initializer.
This particular objection only applies to 'required' initializers, though.
For similar reasons, you cannot override a method that returns a non-optional value with a method returning an optional value.
Yes, this is true.
Jordan
···
On Jan 27, 2017, at 11:04, Slava Pestov via swift-users <swift-users@swift.org> wrote:
On Jan 27, 2017, at 10:39 AM, tuuranton--- via swift-users <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
I knew there were good reasons for this. Thanks mates.
(I don't personally see a need for a new @nonoverriding feature, by the way.)
27. Jan 2017 22:26 by jordan_rose@apple.com:
···
On Jan 27, 2017, at 11:04, Slava Pestov via swift-users <>> swift-users@swift.org>> > wrote:
On Jan 27, 2017, at 10:39 AM, tuuranton--- via swift-users <>>> swift-users@swift.org>>> > wrote:
Yes, but why?
What's the rationale for this?
What would be so bad about allowing overriding a non-failable initializer with a failable initializer?
If the non-failable initializer witnesses a non-failable protocol requirement, and the subclass overrides it, what should be the runtime behavior if the subclass initializer returns nil? The caller won’t expect it, since the caller is calling a non-failable initializer.
This > particular> objection only applies to 'required' initializers, though.
For similar reasons, you cannot override a method that returns a non-optional value with a method returning an optional value.