On 23 June 2017 at 00:36, Brian King <brianaking at gmail.com <brianak...@gmail.com>> wrote:
> A similar syntax has already been proposed and has been `deferred`. There > are a few other links to discussion in the proposal. > > https://github.com/apple/swift-evolution/blob/master/ > proposals/0018-flexible-memberwise-initialization.md > thank you Brian. i like the "default value" idea in those proposals. speaking of lazy vars, maybe just to not have them in the default memberwise initializer param list at all: // this is NOT how the language behaves currently: struct S { var a: Int var b: Int = 0 var c: Int? var d: Int? = nil // same as c var e: Int! lazy var f: Int = { return 0 } () // expected "reasonable" default memberwise initializer autogenerated or opt-in-ed: // // init( // a: Int, // b: Int = 0, // got default value #change // c: Int? = nil, // got implicit default value #change // d: Int? = nil, // got default value #change // e: Int! // no default value - safer // // f is absent due to lazy #change // ) // { // self.a = a // self.b = b // self.c = c // self.d = d // self.e = e // // f is absent due to lazy #change // } } speaking of private var members, if they have an implicit or explicit default value: private var g: Int = ... private var h: Int? private var i: Int? = ... private var j: Int! private var k: Int! = ... they can be omitted from the parameter list of the default memberwise initialiser (#change) similar to how lazy vars are omitted above. if a single private var has no implicit / explicit default value then default member wise initialiser is not created (#change) and attempt to opt-in to have one gives an error. let's call it proposal #5. this particular one is not a backward compatible change, the old code will have to be modified. Mike
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution