or, if you would like to keep your feedback private, directly to the review manager.
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at
* Is the problem being addressed significant enough to warrant a change to Swift?
Yes, the current feature is frustrating. Most notably when:
- some stored properties have default values
- you want to change the access level of the member-wise init
* Does this proposal fit well with the feel and direction of Swift?
I think so. It avoids most boilerplate while staying pretty clear to read.
I see one downside with the chosen syntax: I'm concerned the "..." placeholder might be confusing sometimes.
* 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 read carefully the latest version of the proposal. I partly read the discussion thread.
···
--
Pierre
Le 6 janv. 2016 à 19:13, Chris Lattner <clattner@apple.com> a écrit :
Hello Swift community,
The review of "Flexible Memberwise Initialization" begins now and runs through January 10th. The proposal is available here:
or, if you would like to keep your feedback private, directly to the review manager.
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at
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.
Reluctant -1. This is a well-written and well-considered proposal. However,
in the end my opinion is that the improvement it brings to the language is
not worth the significant increase in complexity it entails.
* Is the problem being addressed significant enough to warrant a change to
Swift?
Boilerplate initializers are obnoxious to write but, as other commenters
have mentioned, writing them doesn't actually account for much of how a
programmer's time is spent writing code. The problem this proposal
addresses isn't one of expressiveness or correctness, it's one of
convenience. Features that increase convenience are great, but the
benefit-to-complexity they provide is not all that high.
* Does this proposal fit well with the feel and direction of Swift?
To be honest, I don't think so. The core team has articulated their desire
for Swift to be a small language that lends itself to building great
libraries. Adding significant special-purpose syntactic and semantic
complexity to the language in order to cut down on some boilerplate does
not really serve that goal. (Add to this the fact that initializers are
already complex enough as-is.) A cut-down version of this proposal could
satisfy the most common use cases for synthesized initializers, with
complex cases deferred to a point where we have a better tool for handling
them (like a macro system).
* If you have you used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
n/a
* How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?
I've read through both relevant discussion threads with varying levels of
attentiveness, as well as the proposal itself.
Best,
Austin
···
On Wed, Jan 6, 2016 at 10:13 AM, Chris Lattner <clattner@apple.com> wrote:
Hi there,as others have already pointed out, I think the proposal introduces a lot of new complexity that is not compensated by its advantages:- It is brittle. Changing the order of members is no problem today, but it will break compatibility when initializers are generated in the proposed way. The same is true when you refactor and move a member to a superclass.- No default values for constants- Quite big addition to the language (especially when all possible extensions of the proposal are accepted as well)- The "..." can lead to confusion, there's to much magic involvedImho the last point is a possibility to improve the proposal in a significant way:The three dots are just a placeholder - why not simply be a little bit more detailed?> init(self x: Int, self y: Int = 0, self z: Int = 0) {}is quite verbose, but the following is more concise yet much easier to understand than "..."init(x, y = 0, z = 0) {}Afaik, single words currently aren't used in method declarations, so the compiler doesn't need "self".I myself am not really happy with this syntax, but at least it really solves some problems:- Less boilerplate (but more than in the proposal)- Default value for constants (better than the proposal)- No "memberwise" keyword required (better)- It's robust: You can rearrange parameters and members without breaking anything (better)You have to type more characters than "...", but autocompletion could help here as it does in other situations, and right now, I rarely see initializers with more than three parameters (although this could be caused by the annoying repetition in current initializers).Best regards,Roger