添加一个可用的初始化程序,其签名与超类的便捷初始化程序(Swift)

时间:2016-01-06 05:06:46

标签: swift swift2

我想知道为什么我无法为init?()定义SubView。编译器使用Failable initializer 'init()' cannot override a non-failable initializer使我感到温暖。但是,根据我的理解,convenience init不会被视为子类中的override,因为如果我将override添加到init?()Initializer does not override a designated initializer from its superclass,则编译会让我感到温暖。

我对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")
    }
}

1 个答案:

答案 0 :(得分: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
    }
}

更新

从我们的讨论中我认为,“缺少胶水”#39;正确理解Swift中的初始化是对' convenience'的解释。属性/关键字。 init()convenience init()之间有什么区别?如果我们不提供任何指定的初始值设定项,Swift使用默认值,可以用签名init(){} /无参数/来解释。如果我们定义自己的init(){ .... }版本,编译器将使用我们的版本。在指定的init(){ ... }init?(){ ... }中,我们无法引用selfconvenience init(){ ... }convenience init?() { ... }我们可以并且主要是我们这样做。否则convenience就没有必要了。编译器可以使用哪个初始化程序,如果我们要使用相同的签名/相同参数定义其中两个/?没有机会选择它!

// 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