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

[Taras Zakharko]

> * What is your evaluation of the proposal?

-1 in its current form

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

Yes and no. First of all, I do not believe that writing initialisers is that much of a hassle to justify the proposal. Also, it makes the language even more idiosyncratic and introduces additional compiler magic. We should strive to make Swift simpler, not adding more syntactic constructs with idiosyncratic behaviour. 

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

IMO, no. See above

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

No

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

Quick reading, nothing in-depth

> On 10 Jan 2016, at 19:38, Michel Fortin via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> * 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
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution