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

[Kevin Ballard]

> 	* What is your evaluation of the proposal?

+1 to the basic proposal. I'm much more reserved about the "Future enhancements"; some I don't want at all, some sound plausible but probably need changes.

Also, a question and a concern about the basic proposal. The question: you state that the only impact this has on existing code is structs with private properties that have been getting an implicit internal memberwise initializer will have the initializer be private. That's fine, but assuming that the implicit memberwise initializer behaves identically to `memberwise init(...) {}`, surely this proposal also makes the implicit memberwise initializer gain defaulted arguments for any var properties with an initializer expression? Don't get me wrong, I think it's good to change that, but it should be explicitly noted.

As for my concern, it's with the following rule:

> If the initializer body assigns to a var property that received memberwise initialization synthesis report a warning. It is unlikely that overwriting the value provided by the caller is the desired behavior.

I understand why you put this in there, but this is a warning that cannot be suppressed and will make it impossible to use a memberwise initializer for perfectly legitimate cases where you do in fact want to mutate the property after it's been assigned to.

What might be a reasonable thing is a warning that occurs if you assign to the var property without ever having read from it (i.e. a dead store warning on the memberwise initialization of the property). That way if I mutate a property to contain a derived value it's fine, but if I simply write to it without ever reading it, it's a problem.

> 	* Is the problem being addressed significant enough to warrant a change to Swift?

I think so. Writing initializers can be a large source of boilerplate in Swift, especially when using classes where you can't get the implicit memberwise initializer.

> 	* Does this proposal fit well with the feel and direction of Swift?

Yes.

> 	* If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I'm not aware of a similar feature in any language I'm familiar with.

> 	* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I spent a few minutes reading over the whole proposal. I did not read any of the swift-evolution thread.

-Kevin Ballard