<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 8, 2016, at 11:56 AM, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""><br class="Apple-interchange-newline">On Jan 8, 2016, at 9:46 AM, plx via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">After reading both your response below and also the proposal rather carefully, I agree that the possible issues I raised are all either not real issues or already addressed; thanks again for crafting the proposal and also for taking the time to reply to so much feedback.</div><div class=""><br class=""></div><div class="">That being said, I can’t shake a feeling that, overall, although I am definitely in favor of something along the lines of this proposal, in its concrete details at present this proposal isn’t really sitting anywhere near even a local-optimum on the `(flexibility,complexity) -> functionality` surface, as it were; it seems like both of these are possible:</div><div class=""><br class=""></div><div class="">- (a) make it a bit more flexible, for a high gain in functionality at a low incremental cost in complexity</div><div class="">- (b) make it a bit less flexible, for a modest loss in functionality and a large drop in complexity</div><div class=""><br class=""></div><div class="">…but for (b) it’s just a feeling and I don’t have a specific proposal (this may well be close to a minimum-viable-proposal for such a feature).</div></div></div></blockquote><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">I agree with you. </div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">As for (b) some people have suggested alternatives with less functionality like David’s `self propName: PropType` suggestion. So far I don’t think any of those add enough value over current state to be worth considering.</div><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><br class=""></div><div class="">For (a) my sense is that although I can understand why you don’t want to even provide the option of specifying an explicit memberwise-parameter list, it really does seem that supporting at least an optional list makes it possible to get a lot more functionality for not much more *actual* complexity; this isn’t incompatible with also supporting an “automatic” option that uses the logic from the proposal where possible.</div></div></div></blockquote><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">In terms of (a), I definitely agree that it would be desirable to allow for a bit more functionality. That is why I have suggested several enhancements. I don’t think we want all of them, but some are definitely desirable. </div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">Chris really wanted to start with a core proposal and evaluate the enhancements independently, which is a good idea but also makes the proposal slightly less flexible than desirable. The enhancements I feel are most important are:</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="">1. We need a way to specify a default value for memberwise parameters for `let` properties.</div><div class="">2. We need a little bit more control over which properties participate in memberwise initialization when the “automatic” rules don’t quite do the right thing for a particular use case. I think allowing distinct access control for `init` is the best way to handle this.</div></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">You mention specifying an explicit parameter list but don’t really elaborate further. Would the opt-in model described in the proposal meet what you have in mind? Or are you also consider with parameter order being independent of property declaration order?</div></div></blockquote><div><br class=""></div><div>I included a mock syntax in my initial response but it was (a) at the end and (b) perhaps a bit too terse. I have put a restated sketch at the bottom of this response.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">Your example below hints at general parameter forwarding. I’ll elaborate further down.</div><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><br class=""></div><div class="">Here’s a concrete example to illustrate why I’m harping on this point; I apologize for the length, but I think “small-n” examples can often give false intuition into how things will behave in real life:</div></div></div></blockquote><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">Thank you for this! I probably should have provided at least one more concrete example myself. I am learning from that mistake in the second draft of my next proposal.</div><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><br class=""></div><div class=""><div class="">class FancyCollectionViewDriver : NSObject, UICollectionViewDataSource, UICollectionViewDelegate /*, etc... */ {</div><div class=""> </div><div class=""> let collectionView: UICollectionView</div><div class=""> let contentPresentation: ContentPresentation </div><div class=""> let modelBroker: ModelBroker</div><div class=""> let imageBroker: ImageBroker</div><div class=""> let analyticsSink: AnalyticsSink</div><div class=""> private(set) var currentData: ModelData</div><div class=""> private(set) weak var interactionDelegate: DriverDelegateProtocol?</div><div class=""> // ^ can't be non-optional `unowned let` for reasons,</div><div class=""> // but we expect a non-nil argument in init</div><div class=""><div class=""> // NOTE: numerous private state-tracking variables omitted since we are only focusing on initialization</div></div><div class=""><br class=""></div><div class=""> // Present-day initializer, full of boilerplate:</div><div class=""> required init(</div><div class=""> collectionView: UICollectionView, </div><div class=""> contentPresentation: ContentPresentation,</div><div class=""> modelBroker: ModelBroker,</div><div class=""> imageBroker: ImageBroker,</div><div class=""> analyticsSink: AnalyticsSink,</div><div class=""> // note use of different argument name:</div><div class=""> initialData: ModelData,</div><div class=""> // note use of non-optional:</div><div class=""> interactionDelegate: DriverDelegateProtocol) {</div><div class=""> // oh boy here we go again:</div><div class=""> self.collectionView = collectionView</div><div class=""> self.contentPresentation = contentPresentation</div><div class=""> self.modelBroker = modelBroker</div><div class=""> self.imageBroker = imageBroker</div><div class=""> self.analyticsSink = analyticsSink</div><div class=""> self.currentData = initialData</div><div class=""> self.interactionDelegate = interactionDelegate</div><div class=""> super.init()</div><div class=""> // only non-assignment logic in the entire init:</div><div class=""> self.collectionView.dataSource = self</div><div class=""> self.collectionView.delegate = self</div><div class=""> }</div><div class=""> </div><div class=""> // best we can do under proposal w/out modifying </div><div class=""> // class design:</div><div class=""> required memberwise init(</div><div class=""> // lots of boilerplate gone:</div><div class=""> ..., </div><div class=""> // this isn't changed:</div><div class=""> initialData: ModelData,</div><div class=""> // this isn't changed:</div><div class=""> interactionDelegate: DriverDelegateProtocol) {</div><div class=""> // synthesized stuff is effectively here</div><div class=""> self.currentData = initialData</div><div class=""> self.interactionDelegate = interactionDelegate</div><div class=""> super.init()</div><div class=""> // only non-assignment logic in the entire init:</div><div class=""> self.collectionView.dataSource = self</div><div class=""> self.collectionView.delegate = self</div><div class=""> }</div><div class=""> </div><div class="">}</div></div><div class=""><br class=""></div><div class="">…which I do think is already a huge improvement. </div></div></div></blockquote><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">And gets even better if we allow access control for init. Your `private(set)` members would now become eligible for memberwise initialization in an `internal` initializer because `init` has a distinct access level which defaults to `internal`.</div></div></blockquote><div><br class=""></div><div>Indeed, but please do note that I’d still like:</div><div>- `initialData` instead of `currentData`</div><div>- a non-nil `interactionDelegate` at init</div><div><br class=""></div><div>That said, I feel that e.g. for any variable declaration syntax something like `private(set) internal(init=initialData) var currentData: ModelData` would be best avoided, even if it’d buy me the ability to customize the name in the synthesized memberwise init; it’s just too much and IMHO sets a bad precedent.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""> <br class=""> required memberwise init(...) {<br class=""> // synthesized stuff is effectively here<br class=""> super.init()<br class=""> // only non-assignment logic in the entire init:<br class=""> self.collectionView.dataSource = self<br class=""> self.collectionView.delegate = self<br class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class=""> }</div></div></div></div><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><br class=""></div><div class="">Now suppose that stored-properties-in-extensions hits (as the "partial-init" flavor); in that case I’d ideally be able to move some of the parts into their own files like so:</div><div class=""><br class=""></div><div class=""><div class="">// in `FancyCollectionViewDriver+Analytics.swift`</div><div class="">extension FancyCollectionViewDriver {</div><div class=""> // ^ depending on advances in the protocol system, at some point may </div><div class=""> // evolve into a protocol-adoption to get useful default implementations</div><div class=""> </div><div class=""> let analyticsReporter: AnalyticsReporter </div><div class=""> // ^ moved here, not in main declaration</div><div class=""> // assume also a bunch of private state-tracking stuff...</div><div class=""> </div><div class=""> // a bunch of things like this:</div><div class=""> func reportEventTypeA(eventAInfo: EventAInfo)</div><div class=""> func reportEventTypeB(eventBInfo: BventAInfo)</div><div class=""> </div><div class="">}</div><div class=""><br class=""></div><div class="">// in `FancyCollectionViewDriver+Interaction.swift`</div><div class="">extension FancyCollectionViewDriver {</div><div class=""> </div><div class=""> private(set) var interactionDelegate: DriverDelegateProtocol?</div><div class=""> // ^ moved here, not in main declaration</div><div class=""> // assume also a bunch of private state-tracking stuff...</div><div class=""> </div><div class=""> // a bunch of things like this:</div><div class=""> func handleInteractionA(interactionAInfo: InteractionAInfo)</div><div class=""> func handleInteractionB(interactionBInfo: InteractionBInfo)</div><div class=""> </div><div class="">}</div></div><div class=""><br class=""></div><div class="">…(and so on for e.g. the `imageBroker` also), but under the current proposal this would put them outside the scope of a memberwise init (this isn’t news to you, I’m just making it concrete).</div><div class=""><br class=""></div><div class="">So in this scenario, we’re either reapproaching the MxN problem memberwise-init is meant to avoid:</div><div class=""><br class=""></div><div class=""><div class="">init(</div><div class=""> // still save some boilerplate:</div><div class=""> …, </div><div class=""> imageBroker: ImageBroker,</div><div class=""> analyticsReporter: AnalyticsReporter, </div><div class=""> initialData: ModelData, </div><div class=""> interactionDelegate: DriverDelegateProtocol) {</div><div class=""> // some boilerplate synththesized here...</div><div class=""> // ...but getting closer to where we started:</div><div class=""> self.partial_init(imageBroker: imageBroker)</div><div class=""> self.partial_init(analyticsReporter: analyticsReporter)</div><div class=""> self.currentData = modelData</div><div class=""> self.partial_init(interactionDelegate: interactionDelegate) </div><div class=""> super.init()</div><div class=""> self.collectionView.dataSource = self</div><div class=""> self.collectionView.delegate = self</div><div class="">}</div></div><div class=""><br class=""></div><div class="">…or we’re making choices between taking full-advantage of properties-in-extensions (which IMHO would often be a *huge* readability win) versus taking full-advantage of boilerplate-reduction in our inits.</div></div></div></blockquote><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">If extensions with stored properties are going to properly encapsulate their state (I believe this is the way to go) they are going to have to initialize state on their own and the primary initializer will have to provide arguments the initializer requires. Allowing stored properties in extensions automatically appear in a memberwise initializer violates that encapsulation.</div></div></blockquote><div><br class=""></div><div>"Automatic appearance" would definitely be bad; it’d seem like using such extensions would have to get you disqualified for automatic synthesis.</div><div><br class=""></div><div>It’s still a tricky point though given the uncertainty about future directions; there seems to be some discussion of allowing protocols to define (instead of merely require) stored properties, which would perhaps be yet-another wrinkle to have to at least consider.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">The good news is that a general parameter forwarding mechanism can help if the extension init (or super init) requires a bunch of arguments and you just want to forward them from your caller. This is alluded to in the enhancement section of the proposal but is really a completely general and orthogonal feature.</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">It might look something like this:</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">memberwise init(…superArgs, …partial1args, …partial2args, …memberwise) {</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>extension1.init(directArgument: 42, …partial1args)</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>extension2.init(…partial2args)</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>super.init(…superArgs)</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">}</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">A couple things to note about how this might work:</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">1. The initializer calls (or function / method calls in other cases) must be unambiguous from the code alone.</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">2. Any parameters for which a direct argument is not provided are “captured” by the `…identifier` placeholder. </div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">3. Parameters matching those captured by the identifier are synthesized in the location specified in the parameter list.</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">Obviously this won’t help if the extensions only require a single argument. But if you have extensions requiring several arguments that you want to pass through it would help</div><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><br class=""></div><div class="">Which is ultimately why I suspect that the “right" version of the proposed feature should cut to the chase and incorporate some way to explicitly-specify the memberwise parameter list — which, again, need not be incompatible with the ability to request automatic synthesis using logic ~ what’s in the proposal — as such an explicit list takes the pressure off of getting the default behavior as-right-as-possible while also making it simpler to support some very nice-to-have capabilities not supported by this proposal as-written.</div></div></div></blockquote><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">How would this be different than the opt-in model described in the proposal? Do you have something specific in mind?</div></div></blockquote><div><br class=""></div>This is what I had in the original. To expand what I meant a bit:</div><div><br class=""></div><div>- you’d a type into “memberwise" by including `@memberwise` somewhere in the declaration</div><div>- `@memberwise` can be used two ways:</div><div> - “bare" `@memberwise` => try to use the automatic approach (~ the logic in this proposal, or similar)</div><div> - `@memberwise($parameterList)`, for explicit lists</div><div><br class=""></div><div>…with some examples for the $parameterList in a second.</div><div><br class=""></div><div>Assume a class like so:</div><div><br class=""></div><div>class Example {</div><div> let foo: Foo</div><div> var bar: Bar = Bar.standard</div><div> var baz: Baz = Baz.standard</div><div>}</div><div><br class=""></div><div>Then here are some @memberwise declarations:</div><div><br class=""></div><div>@memberwise => init(foo: Foo, bar: Bar = Bar.standard, baz: Baz = Baz.standard)</div><div>// ^ automatic, roughly ~ proposal</div><div><br class=""></div><div>@memberwise(foo,bar,baz) => same as above</div><div>// ^ explicit, but identical</div><div><br class=""></div><div>@memberwise(foo,baz,bar) => init(foo: Foo, baz: Baz = Baz.standard, bar: Bar = Bar.standard)</div><div>// ^ explicit, but reordered arguments</div><div><br class=""></div><div><div>@memberwise(foo,bar=Foo.funkyAlternative,baz) => init(foo: Foo, bar: Bar = Bar.funkyAlternative, baz: Baz = Baz.standard)</div><div>// ^ explicit, alternate default for `bar`</div><div class=""><br class=""></div></div><div>@memberwise(foo,bar=,baz) => init(foo: Foo, bar: Bar, baz: Baz = Baz.standard)</div><div>// ^ explicit, suppress default for `bar`</div><div>// …”suppression" syntax isn’t great but it would seemingly work...</div><div><br class=""></div><div><div>@memberwise(foo=Foo.common,bar,baz) => init(foo: Foo = Foo.common, bar: Bar = Bar.standard, baz: Baz = Baz.standard)</div><div>// ^ explicit, provide default for the `let`-property `foo`</div><div><br class=""></div><div>…and perhaps even the ugly-but-serviceable renaming support like:</div><div><br class=""></div><div>@memberwise(foo,bar,baz as initialBaz=) => init(foo: Foo, bar: Bar = Bar.standard, initialBaz: Baz)</div></div><div><br class=""></div><div>…but not sure how to have a non-awful syntax for the case where you want to “promote” a property that’s internally optional to the non-optional case (or vice-versa I guess, or some more-general not-the-same type; that may be out-of-scope).</div><div><br class=""></div><div>Note that something like the above would also offer a natural way to handle superclass initialization:</div><div><br class=""></div><div>@memberwise(…,$parameterList) => this type’s parameters come *after* parent classes’ (memberwise) parameters</div><div><div>@memberwise($parameterList, ..) => this type’s parameters come *before* parent classes’ (memberwise) parameters</div><div><br class=""></div><div>…although I’m not sure how often that’d come up in practice.</div><div><br class=""></div><div>This is not a concrete proposal; it’s just a sketch of how an explicit parameter-list could be designed to still support the automatic approach when possible. I’m assuming that it’s a compiler error to have an explicit list that is either (a) incomplete or (b) has any invalid/unrecognized property names.</div><div><br class=""></div><div>It also feels weird to have an @-style annotation *inside* a type, so there’s a lot of room to improve the proposed syntax.</div><div><br class=""></div><div>And all the other arguments against the explicit list would also still apply, of course.</div><div><br class=""></div></div><div><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><br class=""></div><div class="">That’s my 2c; thanks to anyone who’s read through all this and thanks again for drafting a concrete-enough proposal to discuss properly.</div></div></div></blockquote><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">Thanks for all your feedback and your example! I really appreciate it!</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">Matthew</div><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 7, 2016, at 9:24 AM, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class="Apple-interchange-newline">On Jan 7, 2016, at 9:02 AM, plx via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">I like the general notion of something along these lines but admittedly haven’t had time to dig into the proposal specifics yet.<br class=""><br class="">I have some concerns about cross-interactions with other features that are either also under discussion or are at least very anticipatable.<br class=""><br class="">First, I know there has already been some discussion of allowing definition of stored fields in (some) extensions (e.g., something like allowing definition of stored fields in extensions within the module that defines the type).<br class=""><br class="">E.G., something like this may become possible (assume all files are compiled together):<br class=""><br class=""> // in `ComplicatedClass.swift`<br class=""> class ComplicatedClass {<br class=""> let text: String<br class=""><br class=""> // how will this get expanded,<br class=""> // given the extensions below?<br class=""> memberwise init(...)<br class=""> }<br class=""><br class=""> // in `ComplicatedClass+Foo.swift`<br class=""> extension ComplicatedClass {<br class=""> var fooData: Foo? = nil<br class=""> // presumably stuff-involving-`fooData`<br class=""> }<br class=""><br class=""> // in `ComplicatedClass+Bar.swift`<br class=""> extension ComplicatedClass {<br class=""> var barData: Bar = Bar.standardBar<br class=""> // presumably stuff-involving-`barData`<br class=""> }<br class=""><br class="">It doesn't seem impossible to specify how the memberwise-initialization would interact with constructs like the above, but I'd worry a bit about it making a feature that's already looking *rather* complicated even more so.<br class=""><br class="">Especially since, if I had to pick just one, I'd think the ability to define stored properties outside the initial definition is a bigger win than a nice memberwise-initialization construct, even though both seem handy.<br class=""></blockquote><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">I followed the stored-properties-in-extensions discussion reasonably closely. My understanding is that the extension will need to initialize its own properties, either with an initial value or with a `partial init`. Designated initializers would be required to call the `partial init` for any extension that defines one.</span><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">This being the case, memberwise initialization would not directly interact with this feature at all. Memberwise initializers declared in the main body of type itself would only expose stored properties defined in the type itself. </span><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">It would also be possible to support `partial memberwise init` in extensions which would expose the stored properties declared in the extension as part of a partial initializer.</span><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">I don’t think there are difficult complications here.</span><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class="">Secondly, I’m a bit unsure how this will interact with e.g. the property-behavior proposal if both wind up ratified. For `lazy`, the interaction with `memberwise` is easy — it is omitted from the list — but when you get into e.g. something like a hypothetical `logged` or `synchronized` or `atomic` — wherein there is custom behavior, but the field would still need initialization — you’d want them to be included in the<br class="">`memberwise` init.<br class=""></blockquote><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">My thought here is that a behavior would define whether a property allows and / or requires initialization in phase 1 or not. This is probably necessary independent of memberwise initialization. Properties that allow or require phase 1 initialization would be eligible for memberwise initialization. Properties that don’t allow phase 1 initialization would not be eligible for memberwise initialization.</span><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class="">It’s a bit unfair to bring up another proposal, but this proposal and something like the property-behavior proposal *would* need to work well together (if both are approved).<br class=""></blockquote><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">Agreed. That is why there is a rule that references property behaviors in the proposal.</span><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class="">Thirdly, I’m not sure what the current plans are (if any) for users to be able to specify the precise memory-layout of a struct; apologies if this is already a feature, I simply haven’t looked into it.<br class=""><br class="">**Today**: I order stored-field declarations for ease-of-reading (e.g. grouped into logical groups, and organized for ease-of-reading).<br class=""><br class="">**Under Proposal**: I sometimes will get to choose between the “ease-of-reading” declaration ordering and the “cleanest-reading memberwise init” declaration ordering. These may not always be identical.<br class=""></blockquote><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">Agree. This is something that could be addressed in a future enhancement if necessary. This proposal is focused on the basic mechanism.</span><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">Also, nothing in the proposal prevents you from continuing to write a manual initializer when the synthesized initializer will not do what you require. If you are already explicitly restating the property identifiers to specify parameter order you are already half way to a manual initializer implementation. </span><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">Granted, if you need more than one memberwise initializer you would have to duplicate that effort. But re-ordering is going to have a hard time providing enough value if the basic feature does what we need in the majority of cases.</span><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class="">**Future?**: I may have to choose between the “ease-of-reading” declaration ordering, the “cleanest-reading member wise init” declaration ordering, and (perhaps?) the “intended memory-layout” declaration ordering.<br class=""><br class="">I don’t want to make this proposal more-complicated than it already is, but I worry a bit about having too many things impacting the choice of how to order declarations in source files; it may be better to include a way to explicitly declare the ordering-for-memberwise:<br class=""><br class="">E.G., some way of explicitly indicating the memberwise ordering, perhaps like this:<br class=""><br class=""> // syntax example re-using `ComplicatedClass`<br class=""> class ComplicatedClass {<br class=""> @memberwise($parameterList)<br class=""> // ^ can use just @memberwise to get default ordering + the defaults from<br class=""> // the property declarations, but perhaps require the explicit listing<br class=""> // whenver the ordering is not well-defined (e.g. if you have properties<br class=""> // declared in extensions…then you need to order it yourself)<br class=""> //<span class="Apple-converted-space"> </span><br class=""> // @memberwise(text="Example",barData=,fooData)<br class=""> // - `text="Example"` => memberwise init has text="Example"<br class=""> // - `barData=` => memberwise init has `barData` w/out default<br class=""> // - `fooData` => memberwise init has `fooData` w/default if it has one<br class=""> //<br class=""> // …and e.g. the above would make:<br class=""> //<br class=""> // memberwise init(...)<br class=""> //<br class=""> // ...expand-to:<br class=""> //<span class="Apple-converted-space"> </span><br class=""> // init(text:String = "Example", barData: Bar, fooData:Foo?=nil)<br class=""> //<br class=""> // ...and with the @memberwise declaration supporting a `...` for `super`<br class=""> // placement, like so:<br class=""> //<br class=""> // // superclass members come before:<br class=""> // @memberwise(...,)<br class=""> // @memberwise(...,$parameterList)<br class=""> //<br class=""> // // superclass members come after <br class=""> // @memberwise(,...)<br class=""> // @memberwise($parameterList,...)<br class=""> //<br class=""> // ...perhaps with tweaked syntax (`@memberwise(...,$)` or `@memberwise(...,self)`)<br class=""> // to be bit easier to read when you don't have an explicit parameter list?<br class=""> }<br class=""><br class="">...which of course potentially only-further complicates the feature in some ways, but avoids having this use of this feature *necessarily* impact how one might choose to order declarations?<br class=""><br class=""><blockquote type="cite" class="">On Jan 6, 2016, at 4:47 PM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">Hello Swift community,<br class=""><br class="">The review of "Flexible Memberwise Initialization" begins now and runs through January 10th. The proposal is available here:<br class=""><br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0018-flexible-memberwise-initialization.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0018-flexible-memberwise-initialization.md</a><br class=""><br class="">Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at<br class=""><br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""><br class="">or, if you would like to keep your feedback private, directly to the review manager.<br class=""><br class="">What goes into a review?<br class=""><br class="">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:<br class=""><br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>* What is your evaluation of the proposal?<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>* Is the problem being addressed significant enough to warrant a change to Swift?<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>* Does this proposal fit well with the feel and direction of Swift?<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>* If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br class=""><br class="">More information about the Swift evolution process is available at<br class=""><br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span><a href="https://github.com/apple/swift-evolution/blob/master/process.md" class="">https://github.com/apple/swift-evolution/blob/master/process.md</a><br class=""><br class="">Thank you,<br class=""><br class="">-Chris<br class="">Review Manager<br class="">_______________________________________________<br class="">swift-evolution mailing list<br class="">swift-evolution@swift.org<br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></blockquote><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></blockquote></div></blockquote></div><br class=""><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=eLFMrKDT8iBxZ-2Fbnk-2BZqvSchNN-2FvYXdceA0T7VxwkAc5SwvdOPjliCNfItT-2F2QfD1ywIBqsVdfvxrL1s5a7-2FkLPIZ0V1xtfF5F7I5tLlsGVmZRCGu6jMwA5LOh1RZwzDf3WMcDAqkxLGXGUHt5o2Fqvv0siRMpMyf-2BVG0X4NoyDeMrp1HZSknCe3J3RiLne8atgiYGDNsESvsU9joVzRkCC4U9PvOp-2F-2FgTByiphgwmg-3D" alt="" width="1" height="1" border="0" class="" style="height: 1px !important; width: 1px !important; border-width: 0px !important; margin: 0px !important; padding: 0px !important;"></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div></blockquote></div><br class=""></body></html>