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

[Thorsten Seitz]

* What is your evaluation of the proposal?

I’m generally in favor of the proposal with a small caveat: 

Quite recently a discussion started about an idea by Dave Abrahams and Joe Groff on making use of a more generic approach roughly based on an implicit "members" tuple which requires some language support like forwarding tuples as function arguments and possibly more which would probably be very useful for other use cases besides initialization, e.g. updating an instance with the properties of another instance (usable for mementos or copying) and other things.
It is not yet clear how exactly this might look like (Paul Cantrell, myself and others tried to to some initial brain storming on this and I don’t know whether Dave and Joe have more details worked out already) so I do not know yet whether that idea might replace this proposal. As I would prefer to have a more general (and ultimately more powerful) solution if possible I would like to suggest to keep this alternative approach in mind when deciding whether this proposal will be accepted, maybe even by putting the decision on hold for a short time during which to explore the alternate solution space a bit more in detail.
Matthew Johnson is currently fleshing out some ideas which might possibly combine both approaches (if I understood correctly). These should be considered as well when deciding whether a more general solution might be preferable.
—

On further note I’d like to add that I like marking the memberwise initializer with both a keyword (stands out clearly and is in line with „convenience“) and the „…“ placeholder which makes clear that the initializer takes arguments without them being written out in detail. „…“ is well chosen for that purpose (and can be extended with qualifiers as Matthew did point out if that might become necessary).

I’m against rule #6 of the algorithm as written and request the following change (to fit a suggestion by Kevin Ballard): "If the initializer body assigns to a var property that received memberwise initialization synthesis report a warning if there were no prior reads of this property in the initializer body"


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

Yes. Initialization is a very important part to get right and many languages have deficiencies in that area. I like the design decisions of the Swift team here like designated and convenience initializers. Getting boilerplate removed from the initialization process in a clean way is a good idea.


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

I think it fits well with the concepts of designated and convenience initializers and strikes the right balance between readability and succinctness.


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

Scala has a different approach which puts all properties into the primary initializer argument list which is great for simple cases but starts getting unwieldy fast IMO. 
Ceylon allows putting the properties into the class’s initializer parameter list (with access modifiers similar to Scala) or alternatively to just put the names of the properties into the class’s parameter list (i.e. without access modifiers or type declarations). If more than one initializer is required Ceylon resorts to something similar to standard Swift initializers, requiring the same boilerplate. I prefer this proposal to both of them as it is much cleaner. 


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

I followed the discussion and did take part in it a little bit. I read the proposal and tried to evaluate the alternate idea with the „members“ tuple. Furthermore I looked up the initialization process of Ceylon and Scala because I couldn’t remember their details.


-Thorsten 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160110/188eea12/attachment.html>