[swift-evolution] [swift-evolution-announce] [Review] SE-0018 Flexible Memberwise Initialization
Roger Turnbull
rogeturnbull at outlook.com
Sat Jan 9 04:59:37 CST 2016
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160109/5f72407a/attachment.html>
More information about the swift-evolution
mailing list