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

[Michel Fortin]

> * What is your evaluation of the proposal?

At first glance it looks like it should be a simple thing, but a closer look lead me to believe it's conflating two things:

1. stored properties initialization
2. user-visible property values

Stored properties are the internal state, while user-visible properties is the exposed state. Initialization is about setting the internal state. While it's common to have initializers accept values as arguments, in the general case the initializer has to convert them from the external representation to the internal representation while setting the internal state.

For a plain type with only raw stored properties, internal state and exposed state are the same thing, and this proposal is simple and very appealing.

But for more complex types where the internal state does not map one-on-one to the exposed state, the proposal seems suboptimal. What you really want is to call all the publicly available setters, not set the raw values. But that goes against how things work in an initializer, where setters are skipped and the raw values are set directly.

I understand the proposal is trying to work around this problem by inferring things from the visibility attributes, but the rules seems complex, bug prone (because it bypasses the setters), the feature seems incomplete (missing computed properties), and in the end unnecessary (because you can use the setters). I think we'd be better served if there was simply a way to set properties in batch after initialization, perhaps like this:

	var object = MyObject()
	object .= (property1: 1, property2: "a")

(Note: you can *almost* implement this already through reflection and a custom operator taking a tuple.)


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

This proposal is a good way to get back the default memberwise initializer that structs with no initializer get for free, and allow it for classes when it makes sense. It'd be nice to have that.

I'm also of the opinion that it's worth addressing the verbosity of setting multiple properties at once. But for complex types that hide their internal state, I don't think the added complexity for determining the parameter list and the default values is worth it.

Also, I see no reason why a type should have to opt-in (by providing a memberwise initializer) so its users have a convenient way to set properties: it'd be much better to have a general solution that works everywhere.


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

Not sure.


> * 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 any.


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

I read the proposal, and a lot of what was discussed on the list (but not everything).


-- 
Michel Fortin
https://michelf.ca