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

[Janosch Hildebrand]

> * What is your evaluation of the proposal?

-1 with the "added convenience < introduced complexity" rationale that has been mentioned by a few people in this discussion.

At first I was interested in this proposal for the obvious reason of having previously written initializer "boilerplate" and like with any form of boilerplate instinctively desiring to be rid of it. However over the evolution and now review of this proposal I have become much more hesitant.


Firstly, from the discussion it has become clear that this is a hard issue to solve elegantly.

I mostly like the proposed syntax but it adds a lot of additional language surface with complicated semantics for ultimately limited benefit.
Many people (on both the +1 and -1 sides) seem to be agree that this is ultimately only a "partial" solution and that they would like additional capabilities. However from the proposal and the discussion it seems that those would require even more special behaviour and/or syntax, again adding a lot of additional complexity for limited usefulness.


Secondly, over the course of following this discussion I have become increasingly convinced that this is not as big an issue as I first thought.

At least for me it seems that the annoyance towards writing (some) initializers stems mostly from an instinctual reaction to having to perform a repetitive and menial task. Upon reflection it seems the actual mental and physical work is extremely minimal and it's mostly my annoyance at doing so that seems out of proportion. Very little of my time is ultimately spent writing trivial initialization code.

While these initializers are annoying to type out, it is not an error prone task. They are clear and easy to understand, requiring basically no mental overhead to "parse". They can be easily refactored and adapted as needs change.

With the proposal as it stands I can save a few keystrokes here and there. Until my initializer needs a bit of custom work at which point I might need to write it out anyway, use increasingly obscure syntax, start reordering the types properties, etc... The various extensions to this proposal increase the number of initializers that I could "simplify" but at the cost of a much more complex mental model. Now I need to take into account various attributes and declarations to make my initializer(s) work the way I want.

Writing the initializer is something that happens once, reading it will occur many times. And while it's nice to save 50 keystrokes when writing the thing, is it worth the mental overhead required to piece it together in the future?

The oft mentioned alternative `init(foo: Int, bar: Int) { // implicit }` improves on some of these aspects but at that point the work saved is so small as to probably not be worth the bother.

Now I'm not saying the answers here are clear cut but for me, for now, this proposal introduces a lot of complexity to solve a very limited subset of a not so big problem. But I'd be happy to see this topic revisited in the future and this detailed and well though out proposal should definitely be the starting point for any future discussions.


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

Judging from the interest in this topic, probably yes. However it is a minor problem and the current solutions are too costly for too little benefit.


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

Syntactically mostly yes. However Swift strongly favors clarity and simplicity over conciseness and I feel this proposal has issues in that regard.


> * 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?

I've read the proposal (an earlier draft and the current version) and followed the discussion.


- Janosch