<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 11, 2016, at 4:50 PM, Janosch Hildebrand <<a href="mailto:jnosh@jnosh.com" class="">jnosh@jnosh.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><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 class=""><br class=""></div><div class="">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></div></div></div></blockquote><div><br class=""></div><div>Yeah, I thought of those. I went with list because it implies order which is important to this feature while group and set do not imply order. Not sure why the overlap with plist files didn’t occur to me. I guess because I’m used to the plist abbreviation. :)</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=""><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 class=""><br class=""></div><div class="">1) One less attribute to document, understand, maintain, ...</div><div class="">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 class="">3) Having to explicitly spell out the propertylist aids clarity of intent and consequences</div><div class="">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></div></div></blockquote><div><br class=""></div>Fair points. I agree that people usually don’t declare things this way. </div><div><br class=""></div><div>Part of the reason I included this was as a gesture to the people who like the Scala syntax which does declare a bunch of properties in one list. If it was a major source of contention I would take it out.</div><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=""><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 class=""><br class=""></div><div class="">I understand and I'm certainly biased by having mixed feelings about the initializer story in the first place...</div><div class=""><br class=""></div><div class="">My issues with the default values are roughly as follows:</div><div class=""><br class=""></div><div class="">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></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=""><div class="">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 behavior.</div></div></div></div></blockquote><div><br class=""></div><div>I agree it is a bit weird here, but IMO the primary use case is the partial initializer. </div><div><br class=""></div><div>The computed tuple properties seemed to get a lot of interest during the memberwise init review. I generalized the idea from just sugar for a partial init because I realized we could get the those for free (and maybe other memberwise features down the road as well). </div><div><br class=""></div><div>But maybe that was a mistake. Especially since we will eventually be able to do this kind of stuff with macros.</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=""><br class=""></div><div class="">2) If a property has a generally applicable default value -> on the property declaration.</div><div class="">If a property has an applicable default value for a given initializer -> on the initializer argument.</div><div class=""><br class=""></div><div class="">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></div></div></blockquote><div><br class=""></div><div>Sure. Maybe it would make more sense to focus on making memberwise partial init declarations really concise.</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=""><br class=""></div><div class="">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></div></div></blockquote><div><br class=""></div><div>I agree in terms of custom behavior. But simple property assignments are just boilerplate that would ideally be stated as concisely as possible. </div><div><br class=""></div><div>The problem IMO isn’t the repetition as much as the fact that it clutters up your code making the nontrivial stuff stand out less.</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=""><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 class=""><br class=""></div><div class="">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 class="">Although I think plain Swift tuples go more into that direction (albeit less powerful (for now?!)).</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">My larger issues are with:</div><div class=""><br class=""></div><div class="">a) the syntax</div><div class="">... 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 class="">Also I actually quite liked the `init(...)` syntax in your earlier proposal so it's not the `...` per se...</div><div class="">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></div></div></blockquote><div><br class=""></div><div>Syntax is something I don’t care much about as long as it is clear and makes sense, etc. I would change it if a better idea comes up.</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=""><br class=""></div><div class="">b) not having a clear and settled picture of the concepts and ramifications under discussion.</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><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 class=""><br class=""></div><div class="">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></div></div></blockquote><div><br class=""></div><div>Glad you like this part.</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="">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></div></div></blockquote><div><br class=""></div><div>Yes, but that is always the case. :)</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=""><br class=""></div><div class="">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 class=""><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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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></div></div></div></blockquote><div><br class=""></div><div>Lol. :)</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=""><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 class=""><br class=""></div><div class="">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 class=""></div></div><br class=""></div></div></blockquote><br class=""></div><div>Yeah, it’s clear that no one thing will make everyone happy. I’m hoping to find solutions that make most people mostly happy. :)</div><div><br class=""></div><div>Matthew</div><br class=""></body></html>