Needing self when one initialiser method calls another.

Hi all,

​Given the ​following example:

struct Vector {

var x: Double

var y: Double

init() {

*self.init(x: 0, y: 0)*

}

init(x: Double, y: Double) {

self.x = y

self.y = y

}

}

I'm just curious as to why the *self* (in bold) is needed in the init()
that's calling init(x: Double, y: Double)? Can't the compiler infer from
the parameters what should be called?

- Diego

Hi Diego,

Since you have not given the x & y variables initial values, it requires them to be set inside the init. You can write it like below instead of calling the other self.init

struct Vector {
    
    var x: Double
    var y: Double
    
    init() {
        x = 0
        y = 0
    }
    
    init(x: Double, y: Double) {
        self.x = y
        self.y = y
    }

}

Designer . Developer .  Nerd
Jo Albright

···

On Jan 14, 2016, at 11:48 PM, Diego Barros via swift-users <swift-users@swift.org> wrote:

Hi all,

​Given the ​following example:

struct Vector {
  var x: Double
  var y: Double
  
  init() {
    self.init(x: 0, y: 0)
  }
  
  init(x: Double, y: Double) {
    self.x = y
    self.y = y
  }
}

I'm just curious as to why the self (in bold) is needed in the init() that's calling init(x: Double, y: Double)? Can't the compiler infer from the parameters what should be called?

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

Note that the compiler has a poor diagnostic for this case. I created
[SR-430] Poor diagnostic when using delegating initializers without self · Issue #43047 · apple/swift · GitHub a few weeks ago when I found this
issue myself.

···

On Fri, Jan 15, 2016 at 1:35 AM, Jo Albright via swift-users < swift-users@swift.org> wrote:

Hi Diego,

Since you have not given the x & y variables initial values, it requires
them to be set inside the init. You can write it like below instead of
calling the other self.init

struct Vector {

    var x: Double
    var y: Double

    init() {
        x = 0
        y = 0
    }

    init(x: Double, y: Double) {
        self.x = y
        self.y = y
    }

}

Designer . Developer .  Nerd
Jo Albright

On Jan 14, 2016, at 11:48 PM, Diego Barros via swift-users < > swift-users@swift.org> wrote:

Hi all,

​Given the ​following example:

struct Vector {
var x: Double
var y: Double

init() {
*self.init(x: 0, y: 0)*
}

init(x: Double, y: Double) {
self.x = y
self.y = y
}
}

I'm just curious as to why the *self* (in bold) is needed in the init()
that's calling init(x: Double, y: Double)? Can't the compiler infer from
the parameters what should be called?

- Diego
_______________________________________________
swift-users mailing list
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

--
Trent Nadeau

I'm just curious as to why the self (in bold) is needed in the init() that's calling init(x: Double, y: Double)? Can't the compiler infer from the parameters what should be called?

My interpretation: The `self` must be explicit here to differentiate it from `super.init`. You can't use `super.init` in a struct, of course, but in a class this is a super, super crucial distinction, so it's helpful for the compiler to force you to be clear about this in a class. Structs have the same rule simply because it would be more frustrating if it were inconsistent.

···

--
Brent Royal-Gordon
Architechies

The existence of `super` in classes makes sense as to why it's required.

-- diego

···

On 17 January 2016 at 11:23, Brent Royal-Gordon <brent@architechies.com> wrote:

> I'm just curious as to why the self (in bold) is needed in the init()
that's calling init(x: Double, y: Double)? Can't the compiler infer from
the parameters what should be called?

My interpretation: The `self` must be explicit here to differentiate it
from `super.init`. You can't use `super.init` in a struct, of course, but
in a class this is a super, super crucial distinction, so it's helpful for
the compiler to force you to be clear about this in a class. Structs have
the same rule simply because it would be more frustrating if it were
inconsistent.

--
Brent Royal-Gordon
Architechies