swift - 添加与父类(super class)的便利初始化器具有相同签名的可失败初始化器(Swift)

Question

我想知道为什么我无法为SubView定义init?()。编译器用可失败的初始化程序“init()”无法覆盖不可失败的初始化程序来温暖我。但据我了解，方便 init 不会被视为子类中的覆盖，因为如果我将覆盖添加到init，编译会让我感到温暖？( ) 和初始化器不会覆盖其父类(super class)中指定的初始化器。

我对 SubView.init?() 的期望是它不应该被视为对 View.init() 的重写，因为 SubView 不应该首先将便利的初始化程序继承为 SubView.init() 。

import Foundation
import UIKit

class View {
    convenience init() {
        self.init(frame: CGRectZero)
    }

    init(frame: CGRect) {

    }

    required init?(coder aDecoder: NSCoder) {

    }
}

class SubView: View {
    private var value: String!

    init?() {
        super.init(frame: CGRectZero)
    }

    required init?(coder aDecoder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
}

Answer 1

查看这个“不言自明”的示例

class Base {
    var i:Int
    init?(i: Int){
        self.i = i
        if i == 0 {
            return nil
        }
    }
    convenience init() {
        self.init(i: 1)!
    }
}

class C: Base {
    override init?(i: Int){
        super.init(i: 2 * i)
    }
}

var c: C? = C() // C automatically inherits convenience init() from its superclass
c?.i == 2 // true !!!!!

// that is why
class D: Base {
    init?() {
        // error: failable initializer 'init()' cannot override a non-failable initializer
    }
}

更新

根据我们的讨论，我认为，正确理解 Swift 初始化的“缺失的粘合剂”是对“convenience”属性/关键字的解释。 init() 和 convenience init() 之间有什么区别？如果我们不提供任何指定的初始值设定项，Swift 将使用默认的初始值设定项，可以使用签名 init(){}/noparameters/来解释它。如果我们定义自己的 init(){ .... } 版本，编译器将使用我们的版本。在指定的 init(){ ... } 或 init?(){ ... } 中，我们无法引用 self， convenience init(){ ... } 或 convenience init?() { ... } 我们可以，而且大多数情况下我们都会这样做。否则，那里不需要方便。如果我们要使用相同的签名/相同的参数/定义其中两个初始化程序，编译器可以使用哪个初始化程序？没有机会选择!

// your expectation is wrong,
// because initializer is NOT like other methods

class C {
    var i: Int?
    // this compiles here, but see the usage below!
    func foo()->Int {
        i = 1
        return i!
    }
    func foo()->Int? {
        i = nil
        return i
    }
    // convenience or not, it doesn' matter
    init() {
        i = 1
    }

    // with next lines compiler complains
    // because they all have the same signature / same parameters /
    // from you code you call all three initializers
    // the same way
    //
    // let c = C()
    //
    // dynamicType of c depends of the relsut of class constructor (initializer).
    // this result is anyway the REFERENCE, not a value.
    // c will be a variable or constant (probably an optional) which value will
    // be the REFERNCE to created instance (and probably 'null reference')
    // nil is special value in Swift and differs from 'null reference'
    // in case of fail-able initializer the c must be Optional or ImplicitlyInwrappedOptional
/*
    convenience init?() {
        self.init()
    }
    init?() {
        return nil
    }
*/
}
let c = C()
let p1: Int = c.foo()  // 1
let p2: Int? = c.foo() // nil
//let p = c.foo() // error: ambiguous use of 'foo()'

class D {
    var i:Int?
    init() {
        i = 1
    }
}

// by the theory, compiler could be 'smart' enough to choose the
// right version of initializer, but it could have very strong
// consequences to the language as well.

let d1: D = D()
let d2: D? = D()
d1.i  // 1
d2?.i // 1

// but only one is valid if we use fail-able version of init
class E {
    var i:Int?
    init?() {
        i = 1
    }
}
let e1: E? = E()
e1?.i // 1
//let e2:E = E() // error: value of optional type 'E?' not unwrapped