> On Dec 24, 2015, at 5:41 AM, Matthew Johnson via swift-evolution
> <[email protected]> wrote:
>
>
>
> Sent from my iPad
>
>> On Dec 24, 2015, at 5:46 AM, Thorsten Seitz <[email protected]> wrote:
>>
>>
>>> Am 22.12.2015 um 18:30 schrieb Matthew Johnson <[email protected]>:
>>>
>>> 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_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
