[swift-evolution] [Review] SE-0018 Flexible Memberwise Initialization

[David Owens II]

>> Marginally. My main concern is the complexity of the rules, especially when looking at the direction many of the futures take. There are all of these annotations that get put all over that litter the type
>> definition simply to support memberwise inits.
> 
> Maybe I wasn’t clear enough, but I never intended for all of them to be accepted.  They are intended to show different ways to allow a bit more control.
> 
> The proposal only changes current state in a few ways:
> 
> 1. Allow the memberwise initializer to be used in classes
> 2. Allow default parameter values for `var` properties
> 3. Fix the problem the current memberwise initializer has with lazy properties
> 4. Use the `set` rather than `get` visibility for `var` properties
> 5. Allow you to request the memberwise initializer, including:
> 	i. Specify access level, which will result in omission of memberwise parameters for more-private properties
> 	ii. Add additional parameters
> 	iii. include an initializer body
> 
> Are there specific changes in this list that you dislike?

No, I think you’re goal is reasonable and your proposal is well thought out. The problem comes down to the details on how to support it. Each point has a set of gotcha’s that require rules to handle properly. 

It’s simply my opinion that these rules make the feature far too complicated.

You could go super basic and just have the proposal help address the struct scenario and have the default value for “var” members carried through to the implicitly created init(). 

>> I think it keeps coming up because it’s far simpler. While there is duplication in the type signature, the code is still smaller, more flexible, and more applicable than being limited to only initialization. Further, and I think this is what is far more important, I only need to look at single place to understand what is going on with initialization for any particular call. I don’t need to find out what members are annotated, or create the list of head of members and exclude certain ones if @nomemberize() is used. Each member being initialized as a configuration entity from the user is right there, no questions asked.
> 
> How is this more applicable than just for initialization?  Are you suggesting a self parameter be allowed in any method and it would result in an immediate set of that property?

Yes, I’m suggesting that “self” is a qualifier, like “inout”.

This code:

struct Point {
    var x, y, z: Int
    init(self x: Int, self y: Int = 0, self z: Int = 0) {}
    func foo(self x: Int) {}
}

Would be identical to this code:

struct Point {
    var x, y, z: Int
    init(x: Int, y: Int = 0, z: Int = 0) {
        self.x = x; self.y = y; self.z = z;
        // rest of function
    }

    func foo(x: Int) {
        self.x = x
        // rest of function
    }
}

That assignment happens before the function body executes.

This model fixes the majority of my complexity issues. However, it brings some others to the table and doesn’t solve the need to duplicate all of the members in the API.

I think something like this was mentioned before, but I don’t remember what happened with it. However, another way to do initialization could be like this (C# calls this field initializers):

	let p = Point {
        x = 12,
        y = 13,
        z = 14
    }

We then get out of caring about the ordering of the parameters. However, this feature is much more narrow as it only applies to public properties. There is a lot of subtly in actually implementing this in the compiler though.


> I really appreciate the feedback and conversation.  I am continuing to think about all of the comments and am hoping we can come out of this review with a vision for a path forward that makes most people happy whether the proposal is accepted or not.  (I think it’s clear that no solution will make everyone happy but do hope we can hit a sweet spot)

Just to be clear, I think the proposal lays out the land well and has good coverage of the issues. I just find it too complicated of a ruleset to need to know.

-David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160108/8a2adf17/attachment.html>