<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 11 Jan 2016, at 18:17, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div 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;"><b class="">propertylist:</b></div><div 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;">Not a big fan of the name either, `propertyalias` came to mind but that sounds like it's only for a single property.</div></div></blockquote><div class=""><br class=""></div><div class="">If you think of something better please let me know!</div></div></div></div></blockquote><div><br class=""></div><div>I will. There are also a lot of possibilities along the `propertygroup`, `propertyset` axis that share most of the downsides of `propertylist` but at least they wouldn't be too similar to <a href="https://en.wikipedia.org/wiki/Property_list" class="">https://en.wikipedia.org/wiki/Property_list</a>. Although I'm not sure if that naming overlap should be considered a problem.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div 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;"><b class="">@propertylist:</b></div><div 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;">I think this is mostly redundant and the proposal would be improved by its removal.</div></div></blockquote><div class=""><br class=""></div><div class="">Removing it would require a redundant list of property names in some cases. Why do you think that is better?</div></div></div></div></blockquote><div><br class=""></div><div>1) One less attribute to document, understand, maintain, ...</div><div>2) It makes the proposal simpler and clearer focusing more on the basic idea. If it were accepted and it turns out there is a big desire for something like that it could always be added – the reverse is much harder.</div><div>3) Having to explicitly spell out the propertylist aids clarity of intent and consequences</div><div>3) It has a very small use case. I don't think there are a lot of property declarations that would profit from this so I don't think it requires special consideration. At least personally I rarely declare multiple properties on a single line and not all of these might form a logical group.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: 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;"><b class="">[snip]</b></div></div></blockquote></div></div></div></blockquote><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div 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;"><b class="">Default values in propertylist:</b></div><div 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;">Strongly against this. Only applicable to initializer use case and feels generally out of place.</div></div></blockquote><div class=""><br class=""></div><div class="">It is extremely important to the initializer use case. There is no way to provide a default for `let` properties in the initializer without allowing this. I would not have written this proposal at all if it weren’t for a desire to improvise the initializer use case.</div></div></div></div></blockquote><div><br class=""></div><div>I understand and I'm certainly biased by having mixed feelings about the initializer story in the first place...</div><div><br class=""></div><div>My issues with the default values are roughly as follows:</div><div><br class=""></div><div>1) My biggest issue is that it is really weird with regards to the other use case(s) of this idea, that is getters and setters for multiple properties.</div><div>I'm not really sure yet how useful that would be but I find the idea interesting. But default values really don't fit well with it. They aren't really applicable to that use but it feels really weird to have these default values in the declaration and then not have them influence the synthesized behaviour.</div><div><br class=""></div><div>2) If a property has a generally applicable default value -> on the property declaration.</div><div>If a property has an applicable default value for a given initializer -> on the initializer argument.</div><div><br class=""></div><div>I understand that you're introducing a sort of middle ground that is applicable to multiple (related) initializers but I feel it muddles the waters with regards to the other cases and from my perspective has limited use. I'd feel better with something that were still part of the initializer (syntax completely arbitrary): `init(...someGroup default s = "")` but again for me the complexity outstrips the usefulness so I'd be against that too ;-)</div><div><br class=""></div><div>I tend towards requiring one to spell out (at least parts of) the initializer when one wants custom behaviour (or hope for a suitable flexible macro system) so we're probably bound to be at odds in these regards ;-)</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div 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;">[snip]</div></div></blockquote><blockquote type="cite" class=""><div class=""><div 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;"><b class="">Parameter forwarding:</b></div><div 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;">This is the proposal I like the least. I'm not a fan of the syntax and it mostly saves some minor typing at the cost immediately knowing what the actual arguments are.</div></div></blockquote><div class=""><br class=""></div><div class="">Have you used a language with a similar feature (such as tuple packing and unpacking in a dynamic language)? It is quite useful. IMO, removing the clutter of each argument, type, and default value makes it much more clear that simple forwarding is happening.</div></div></div></div></blockquote><div><br class=""></div><div>I'm aware of the concept but I have to admit that I don't have much experience with these features or the respective languages.</div><div>Although I think plain Swift tuples go more into that direction (albeit less powerful (for now?!)).</div><div><br class=""></div><div>I agree that it is visually simpler but I think the visual similarity of the forwarding call (with all arguments) to the function definition is often enough to quickly deduce what is happening while still allowing one to check at a glance what the arguments, types and default values are...</div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">The complete parameter list would still appear in generated documentation, autocomplete, etc. An IDE could also provide an option to view the full parameter list in the function declaration itself.</div></div></div></blockquote><div><br class=""></div><div>I agree that would happen and would be helpful but I can't help but feel that I'd be better served by a much smarter autocompletion than what we have today that would take care of the redundant typing without actually changing the resulting source code.</div><div><br class=""></div><div>My larger issues are with:</div><div><br class=""></div><div>a) the syntax</div><div>... which I dislike. Currently it's more at an emotional than intellectual level so I haven't fully grasped the why and how.</div><div>Also I actually quite liked the `init(...)` syntax in your earlier proposal so it's not the `...` per se...</div><div>At least I'd like to see more discussion and proposals towards what something like that would look like and weigh the options.</div><div><br class=""></div><div>b) not having a clear and settled picture of the concepts and ramifications under discussion.</div><div><br class=""></div><div>This actually applies to all three proposals and the memberwise initializers proposal before as well. I can see that there is a problem being solved and a reasonable proposal for a solution. However I'm neither sure that the problem is big enough to require a or the proposed solution and I'm unsure if the proposed solution is the right one and I feel that I can't yet fully grasp the long term implications.</div><div><br class=""></div><div>In part this is because the problems at hand don't irk me personally enough to want immediate remedy and in a larger part because I simply haven't much if any experience with languages and concepts that (attempt to) solve these issues. I'm really missing a frame of reference as to what the solution-space looks like in these areas and what the respective advantages and disadvantages are – especially since disadvantages of language constructs are often not immediately obvious.</div><div><br class=""></div><div>That's also why I really appreciate these proposals and the related discussions. Currently I feel like I'm still swimming too much in the dark to form a well-reasoned opinion and I'd like to see more approaches, more discussion and get a better feeling of future Swift changes that might impact these areas before settling down. I really don't mind waiting a few years before attempting to solve these issues (if they still exist). I also don't feel the need for a fast (stopgap) solution since these are not fundamental issues to me.</div><div><br class=""></div><div>I'm not sure if that is of much help to you but I hope it explains my current wait-and-see attitude a bit better. YMMV of course :-)</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div 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;"><b class="">Partial initializers:</b></div><div 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;">My dislike of parameter forwarding carries over to this but otherwise I find the basic idea quite nice.</div><div 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;">My bigger issue here is that I currently don't see a huge use case for this that isn't already served by initializer delegation. Yes this seems to cover additional cases but I'm not sure it justifies it's existence. It makes a lot more sense when considered as part of the memberwise initialization trifecta with parameter forwarding but like I said that's the part I don't really like.</div></div></blockquote><div class=""><br class=""></div><div class="">Initializer delegation requires the initializer you call to be a complete initializer. It is not uncommon to have more than one designated initializer that need to share initialization logic. There are techniques to factor out some of this logic today, but it would be much easier with partial initializers. </div></div></div></div></blockquote><div><br class=""></div><div>Indeed! Which is why I like this part of the proposal and agree with what some others have written in response in the respective thread. It is also something that can and perhaps should be decided now. I'm just unsure if there are enough use-cases to justify it. I can think of cases where it would have been useful but not enough to convince me.</div><div>There is also the downside that this can lead to less code duplication at the cost of fragmented and harder-to-follwo logic if abused.</div><div><br class=""></div><div>Currently speaking I have no strong opinion either way and the discussion will probably convince me one way or another but as it stands I would certainly not object to this being added to the language.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div 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;"><b class="">Property Lists:</b></div><div 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;">Like with partial initializers I find this to be an interesting idea and this seems to have other potential use cases apart from memberwise initialization. Then again I'm unsure if this exact proposal is the way to go here. I'd really prefer to see more abstract discussion of this idea before committing to any specifics.</div><div 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=""></div><div 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=""></div><div 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;">Particularly here but also in general for all three proposals I feel that we might be better served by letting the language form further and waiting for more general pieces to fall into place before charging ahead in these areas. None of these require stopgap solutions from my point of view and I at least feel like I could evaluate this much better once I have an idea of what Swift is going to look like at version 4, 5, ...</div><div 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;">From reading the Swift team's comments it seems like future improvements like variadic generics might make a potential difference here and I imagine the macro system might as well.</div></div></blockquote><div class=""><br class=""></div><div class="">These proposals are partly a response to the comments Dave and Joe made about building on more general underlying features.</div><div class=""><br class=""></div><div class="">Partial initializers are a feature that would need to stand on its own, it would not be enabled by any other features. As noted in the proposal, it might actually help to prepare the initialization model to support initialization of extensions and protocols with stored properties.</div></div></div></div></blockquote><div><br class=""></div><div>I would certainly be in favor of extracting partial initialization into a separate proposal without forwarding and have forwarding optionally build on that later. As it stands partial initialization seems more like step 2 of 3.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">I don’t believe variadic generics would cover the full set of forwarding capabilities I would like to see. Particularly forwarding of default values, but also forwarding a subset of parameters. I know you are not a fan of the forwarding idea so that may not matter much to you.</div><div class=""><br class=""></div><div class="">The property list idea could probably be implemented with a powerful-enough macro system. My opinion is that it would be nice to solve this problem in Swift 3 if possible. The feature could be replaced by a macro down the road if it becomes possible to write it that way.</div></div></div></div></blockquote><div><br class=""></div><div>Like I wrote above I fall on the other side of that argument and would rather wait than implement something now. For example I'd first like to see what the variadic generics and macro system look like. However if the Swift team and community decide to implement a solution now and maybe revisit the topic later I won't really mind that on any of these topics.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div 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;">I hope this doesn't sound too negative, you clearly invested a significant amount of work into these proposals and I value the effort. It helps me better understand the problems people see and what potential solutions might look like and stirs a lot of healthy discussion.</div><div 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;">So don't let yourself be discouraged if I don't feel that changes in this area are required just yet :-)</div></div></blockquote><div class=""><br class=""></div><div class="">That’s a fair opinion. The discussion has been healthy indeed! IMO it has at least validated that there is broad support for doing something to address these problems.</div></div></div></div></blockquote><div><br class=""></div><div>Absolutely. Although that alone is not enough to convince me per se. Not a fair comparison really, but there was once broad support for adding GC to objc too ;-)</div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">One of the big critiques of the Flexible Memberwise Initialization proposal was that it wasn’t powerful enough to support all the use cases people want to solve. I think there is a lot of demand to solve these problems and many people would like to see them solved in Swift 3. </div></div></div></blockquote><div><br class=""></div><div>Indeed! And there's probably no solution that fully satisfies everyone. It's also easy to desire increased power or a simpler system but you're the one left to actually present a cohesive solution and argument and defend the resultant complexity or lack of power so I respect your effort and certainly don't envy your position ;-)</div><div><br class=""></div><div>- Janosch</div></div><br class=""></body></html>