<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 class="">This is a legit concern that I didn’t consider before.</div><div class=""><br class=""></div><div class="">I think there are several options, from the most general to the most subtle:</div><div class="">1. Stored type properties are implicit `final`, so behave exactly the same as the current static stored properties.</div><div class="">2. Stored type vars are implicit `final`, as you suggested, so behave exactly the same as the current static stored vars. All other type properties(including stored type lets) are normally overridable.</div><div class="">3. Store type vars are overridable but can not be observed.&nbsp;</div><div class=""><br class=""></div><div class="">There could be a even more subtle option if my understanding of how classes exist in runtime is correct.</div><div class=""><br class=""></div><div class="">In my understanding, classes exist as singleton instances of their meta classes. If it is true, which I believe is the image in most people’s heads if they know about meta classes, then the class objects tree is exactly the same as the class hierarchy tree. Every subclass object contains(or points to) its super class object in its layout. The super class part is shared by all subclass objects and the super class object per se. So stored type properties are conceptually and naturally shared by the super class and all its subclasses, which behave exactly like the current static stored properties.</div><div class=""><br class=""></div><div class="">In this modal, the 4th option is:</div><div class="">4. Stored type vars are overridable and observable. When they are assigned new values, all their property observers defined in the class hierarchy are called, calling order is not significant, the reason of which will be addressed later.</div><div class=""><br class=""></div><div class="">Unfortunately, there is one last catch: if more than one classes assign a value to the property within their didSet observer, the final result is undefined.</div><div class=""><br class=""></div><div class="">This issue can not even be resolved by ordering observer calls from top to bottom in the class hierarchy because we can not meaningfully define the order within the same level if there are more than one subclasses in it.</div><div class=""><br class=""></div><div class="">So one addition to option 4:</div><div class="">4-1. Stored type vars’ didSet observers are not allowed to reassign value to the observed property.</div><div class=""><br class=""></div><div class="">But it is such a corner case that probably this limitation is acceptable.</div><div class=""><br class=""></div><div class="">What do you think? Is my understanding of class objects correct? Which option do you like best?</div><div class=""><br class=""></div><div class="">- Ling</div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Dec 8, 2015, at 5:40 PM, Jordan Rose &lt;<a href="mailto:jordan_rose@apple.com" class="">jordan_rose@apple.com</a>&gt; 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 Dec 7, 2015, at 19:12, Ling Wang via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><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;">Besides, we shouldn’t use `final` to denote storage at all for `final` is about inheritability/overridability not about storage.</div><br class="Apple-interchange-newline"></div></blockquote></div><br class=""><div class="">Please remember that stored properties <i class="">can</i>&nbsp;be overridden in Swift:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">class Base {</div><div class="">&nbsp; /*instance*/ var flag: Bool = true</div><div class="">}</div><div class=""><br class=""></div><div class="">class Sub : Base {</div><div class="">&nbsp; override var flag: Bool {</div><div class="">&nbsp; &nbsp; didSet {</div><div class="">&nbsp; &nbsp; &nbsp; if flag { print("The flag was set!") }</div><div class="">&nbsp; &nbsp; }</div><div class="">&nbsp; }</div><div class="">}</div></blockquote><br class=""><div class="">This is theoretically possible at the class level as well, but doesn't really make sense for what's currently spelled "static var", since you'd be accessing the same storage in different ways. Does the proposal mean that a stored "type var" is non-overrideable, but a computed "type var" is overrideable, implicitly?</div><div class=""><br class=""></div><div class="">Jordan</div></div></div></blockquote></div><br class=""></body></html>