Initializers

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)
    }
}

_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

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)>> }>> }

  >> _______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

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)
    }
}

_______________________________________________
swift-users mailing list
swift-users@swift.org <mailto:swift-users@swift.org>
https://lists.swift.org/mailman/listinfo/swift-users

_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

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.

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)
    }
}

_______________________________________________
swift-users mailing list
swift-users@swift.org <mailto:swift-users@swift.org>
https://lists.swift.org/mailman/listinfo/swift-users

_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

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.

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.

Yes, this is true.
Jordan