Build Error When Trying to Override an Initializer in Xcode 6.3 Beta 3

Build error when trying to override an initializer in Xcode 6.3 Beta 3

A designated initializer of a subclass needs to call the designated initializer of Superclass. A convenience initializer can only call another convenience initializer or a designated initializer of that class.

init() is a convenience initializer for UIView, if you subclass UIView you should call its designated initializer which is init(frame: frame)

override init() {
super.init(frame: frame)
// Some init logic ...
}

EDIT: Apparently in Beta 3, UIView doesn't have convenience initializer called as init, so you need to remove the override keyword too, now this is a designated initializer so you need to call superclass's designated initializer

init() {
super.init(frame: frame)
// Some init logic ...
}

EDIT: Although this works but I think a better way to write this would be:

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

Source:Swift documentation

Rule 1 A designated initializer must call a designated initializer
from its immediate superclass.

Rule 2 A convenience initializer must call another initializer from
the same class.

Rule 3 A convenience initializer must ultimately call a designated
initializer.

Error after update to Swift 1.2

Change your this line :

let originView:UIView!

to

var originView:UIView!

And you are done.

Cannot build my iOS app after update

You must change everything to Swift 1.2 because the latest XCODE version don't support swift 1.1
Here is a great Link about Swift 1.2

Initializer does not override a designated initializer from its superclass

My solution is a quick fix, but I think is easier than what Apple purposes on the the Release Notes. For more information search for 19775924 http://adcdownload.apple.com//Developer_Tools/Xcode_6.3_beta_3/Xcode_6.3_beta_3_Release_Notes.pdf here. What Apple says is that you create an Objective-C file and extend it (having to add it to the header files and all) and it's on "Known Issues in Xcode 6.3 beta 3", so I think is easy to do what I did:

This is how I fixed it for UIButton:

class CustomButton : UIButton {
init() {
super.init(frame: CGRectZero)
}

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

And this is one of my ViewControllers (remove public if not needed):

public class GenericViewController: UIViewController {
public init() {
super.init(nibName: nil, bundle: nil)
}

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

I don't use IB so I also have UIView, because I do separate the view from the viewController (remove public if not needed):

public class GenericMenuView: UIView {
public init() {
super.init(frame: CGRectZero)
}

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

I need this specially in views because I have a setupViews method that I override in all subclasses that is called on the init. And using AutoLayout I don't need any frames (so I don't override the init with the frame parameter).

So it seems you have to drop override. Oh! and be sure to not call self.init() or the class is never initialized (and it crashes after some internal timeout).

Create component with UILabel and UITextdfield

You should get rid of all unnecessary initialisers and make sure that your custom init method calls one of the designated initialisers of super.

final class TextFormField: UIView {
var labelText: String
var secureText: Bool
var keyboardType: UIKeyboardType

init(labelText: String, secureText: Bool, keyboardType: UIKeyboardType){
self.labelText = labelText
self.secureText = secureText
self.keyboardType = keyboardType
super.init(frame: .zero)
}

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

XCode 6.3 Init() No Longer Compiles

You must use the designated initializer of UITableViewController, that is

init(style style: UITableViewStyle)

for example:

super.init(style: .Plain)

How can I override a setter from a SuperClass in Swift with Xcode 6.3 Beta2?

If all we want it do some extra functionality after the selected property as been set, we can simply override to add a property observer:

override var selected: Bool {
didSet {
if self.selected {
// do something
}
}
}

Updated Answer for Swift 5:

override var isSelected: Bool {
didSet {
if self.isSelected {
// do something
}
}
}

If we care about what the previous value of selected was, we can access it via oldValue:

didSet {
if self.selected == oldValue {
return
}
// do something
}

Updated Answer for Swift 5:

didSet {
if self.isSelected == oldValue {
return
}
// do something
}

And don't forget, we can use willSet as well if we need to do something just before the value is changed.


I was curious what would happen when we've got a large hierarchy of classes each adding their own stuff in willSet and didSet property observers, so I created the following test:

class ClassA {
var _foo: Int = 0
var foo: Int {
set(newValue) {
println("Class A setting foo")
self._foo = newValue
}
get {
return self._foo
}
}
}

class ClassB: ClassA {
override var foo: Int {
willSet {
println("Class B will set foo")
}
didSet {
println("Class B did set foo")
}
}
}

class ClassC: ClassB {
override var foo: Int {
willSet {
println("Class C will set foo")
}
didSet {
println("Class C did set foo")
}
}
}

Now, if we create an object of ClassC and set its foo property:

var c: ClassC = ClassC()  
c.foo = 42

We get the following output:

Class C will set foo
Class B will set foo
Class A setting foo
Class B did set foo
Class C did set foo

So, it's important to note a few things from this...

  • A child class's willSet is called before its parent's willSet.
  • A child class's didSet is called after its parent's didSet.
  • Creating an override for the sake of adding property observers does not replace any property observers in the parent classes.

The first two points make a bit of sense. And actually, this makes property observers much more appealing. Effectively, Swift forces our hand into going up and down the heirarchy in the appropriate manner and nicely splits it out into two separate methods. Swift also prevents us (I believe) from overriding a parent class's property, but also still lets us observe changes to that property--this is much better than Objective-C's approach.

But the third point is probably the most important. Be careful--you can easily get bogged down in a massive heirarchy of didSet and willSet code that's slowing down what should be a pretty quick process: setting a property's value.

Initializer does not override a designated initializer while subclassing NSURLSession Swift

You can not.

The only designated initializer is NSURLSession.init() and you must call it from your subclass initializer. NSURLSession configuration, delegate and delegateQueue properties are read-only so you can not manually set them.

The better way is to wrap NSURLSession with custom class:

class NSURLAuthSession {
private let urlSession: NSURLSession

init(urlSession: NSURLSession) {
self.urlSession = urlSession
}
}

thus you will have more control and customization options.

Initializer does not override a designed initializer from its superclass error in swift

You've got a few different errors here; let's deal with them one at at time.

Overriding a convenience initializer

Per the Swift documentation from Apple:

if you write a subclass initializer that matches a superclass convenience initializer, that superclass convenience initializer can never be called directly by your subclass, as per the rules described above in Initializer Delegation for Class Types. Therefore, your subclass is not (strictly speaking) providing an override of the superclass initializer. As a result, you do not write the override modifier when providing a matching implementation of a superclass convenience initializer.

So ditch the override keyword and you should be set. Speaking of sets…

Upgraded interfaces for touch methods in Swift 1.2

Paul Solt of iphonedev.tv covers this in Swift 1.2 fixes and breaks a few things: you should be excited!, and I recommend you read the whole post (not to mention the release notes that he links to), but the short of it is that NSSet has been replaced by a native Set type. As he says:

Fix: You'll need to update your method signature (i.e.: the entire first line) to the following:

override func touchesBegan(touches: Set<NSObject>, withEvent event: UIEvent) {

He also notes that there's no an anyObject() method on Set, so you're going to have to work around that with the interface provided.

Hope that helps!



Related Topics



Leave a reply



Submit