[swift-evolution] [Proposal Draft] Flexible memberwise initialization

[Joe Groff]

> On Dec 24, 2015, at 5:41 AM, Matthew Johnson via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> 
> Sent from my iPad
> 
>> On Dec 24, 2015, at 5:46 AM, Thorsten Seitz <tseitz42 at icloud.com> wrote:
>> 
>> 
>>> Am 22.12.2015 um 18:30 schrieb Matthew Johnson <matthew at anandabits.com>:
>>> 
>>> My proposal is specifically suggesting that we treat “initial value” as a default rather than an initialization that always happens.  IMO the current behavior is limiting and problematic in a number of ways.
>>> 
>>> If we make the change I am suggesting double initialization / assignment will not happen. 
>> 
>> Ah, ok! 
>> 
>> I'm a bit uneasy about overloading the initial-value-syntax with a new meaning, though.
>> 
>> -Thorsten
> 
> This was pulled from the latest draft of the proposal.  Please take a look at the current draft and let me know if you like the new solution better.

I wonder whether we could avoid the problems of mixing up inline initialization and default initializer parameterization by taking a different approach. Sorry if this has been discussed and I missed it, but Scala and Kotlin both support a compact function-like class declaration syntax for simple "case classes". We could adopt something similar for our structs and classes, so that:

public struct Vec4(x: Double, y: Double, z: Double, w: Double = 1.0) { }

expanded to:

public struct Vec4 {
  public let x: Double
  public let y: Double
  public let z: Double
  public let w: Double // NB: No inline initializer

  // Default argument in struct decl becomes default argument in initializer
  public init(x: Double, y: Double, z: Double, w: Double = 1.0) {
    self.x = x
    self.y = y
    /* you get the idea */
  }
}

(and you could presumably stick `var` on parameters to make the corresponding properties `var`s instead of `let`s, if you wanted). That collects all the information you want to know about the members and their initialization together in one place, and the syntax naturally suggests function-like semantics for `=` expressions rather than inline-initializer-like semantics.

-Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151224/00020eb8/attachment.html>