<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=""><div><blockquote type="cite" class=""><div class="">On Dec 7, 2015, at 6:21 PM, Chris Lattner <<a href="mailto:clattner@apple.com" class="">clattner@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On Dec 7, 2015, at 8:13 AM, an0 via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><blockquote type="cite" class="">The coexistence of `static` and `class` keywords for declaring type<br class="">properties and methods is confusing and causes inconsistency between<br class="">type and instance member declarations. This document reasons why we<br class="">don’t need both and suggests we unify them with a better keyword<br class="">`type`.<br class=""></blockquote><br class="">I’m sure you know this, but for folks who haven’t dug through the history, the design team has already implemented, evaluated and rejected this idea. We have also spent a lot of time over the years discussing and debating the issue, and have come to the current approach. Since the Swift 1.2 changes went in, we haven’t seen significant confusion.<br class=""><br class=""><blockquote type="cite" class="">#### Class stored properties VS. static stored properties<br class=""><br class="">If you use the `class` keyword to declare a stored property in a class<br class="">you will get this compiling error:<br class=""><blockquote type="cite" class="">class stored properties not yet supported in classes; did you mean 'static'?<br class=""></blockquote><br class="">So what are class stored properties? How are they different from<br class="">static stored properties?<br class=""></blockquote><br class="">This is a well-defined concept that comes from the Objective-C language, where class methods are dynamically dispatched. We are not willing to sacrifice compatibility with this concept. </div></div></blockquote>I didn’t say anything against "class methods are dynamically dispatched”. Actually my proposal states that type methods are dynamically dispatched by default.<br class=""><blockquote type="cite" class=""><div class=""><div class="">Similarly, we need and want “static” methods in classes for the common case in which dynamic dispatch is not desired.<br class=""></div></div></blockquote>I know it is for performance optimization. But why not use `final`? Also, did you read my optimization concern in this part: <font color="#000000" class=""><a href="https://github.com/an0/swift-evolution/blob/master/proposals/NNNN-unify-static-and-class-keywords.md#impact-on-existing-code?" class="">https://github.com/an0/swift-evolution/blob/master/proposals/NNNN-unify-static-and-class-keywords.md#impact-on-existing-code?</a> How do we enforce “static” dispatching for instance methods that are way more than type methods in most code?</font><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">Further, the current Swift design works well for folks more familiar with Java or C++ object models can just ignore class methods and use static methods. They behave pretty much as they would expect.<br class=""></div></div></blockquote><div class="">Did you read the part about inconsistency between type and instance member declarations(<a href="https://github.com/an0/swift-evolution/blob/master/proposals/NNNN-unify-static-and-class-keywords.md#class-methods-vs-static-methods" class="">https://github.com/an0/swift-evolution/blob/master/proposals/NNNN-unify-static-and-class-keywords.md#class-methods-vs-static-methods</a><a href="https://github.com/an0/swift-evolution/blob/master/proposals/NNNN-unify-static-and-class-keywords.md#class-methods-vs-static-methods?" class="">)</a>? What do you think about it? Do you think compatibilities with other older languages are more important than the consistencies within Swift itself?</div><div><blockquote type="cite" class=""></blockquote></div><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class="">Class stored properties VS. static stored properties<br class=""></blockquote><br class=""><br class="">You list many complaints about class properties, then go on to suggest that we replace “class” with “type”. It seems that your complaints aren’t actually relevant to the proposal, since you’re not actually removing them from the model. In fact, instead of “static var x” you’d have to write “final type var x”, which would be an unfortunate regression.<br class=""></div></div></blockquote><div class="">When you said "You list many complaints about class properties” you meant “class stored properties”, right?</div><div class=""><br class=""></div><div class="">If so I don’t think I’ve ever complained about it because Swift doesn’t support class stored properties yet. My points about class stored properties are:</div><div class="">1. Are they useful enough? Do we want it in Swift?</div><div class="">2. Are we going to add it in Swift? If yes, when?</div><div class="">3. If no, then we only have one kind of type stored properties, why do we need two keywords for them?</div><blockquote type="cite" class=""><div class=""><div class=""><br class=""><br class=""><blockquote type="cite" class="">## Proposed solution: type.<br class=""></blockquote><br class="">This sacrifices all familiarity for folks coming from other extended C-family of languages, is not precedented in a popular language that I’m aware of, and is an unfortunate word to take as a keyword.<br class=""></div></div></blockquote>As said above, I think consistencies within Swift itself are more important than compatibilities and familiarity with other languages.<blockquote type="cite" class=""><div class=""><div class=""><br class="">Beyond that, what you’re attempting to address is pretty much a non-problem. I’m aware of a lot of problems with Swift :-) but I have never seen the Swift 1.2+ design cause practical problems.<br class=""></div></div></blockquote>I know there are a lot other problems that are more urgent than what we are talking about here. But I can’t agree that the inconsistency I mentioned in this proposal is a non-problem. <br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">-Chris<br class=""><br class=""></div></div></blockquote></div><br class=""></body></html>