<div dir="ltr"><span style="font-size:small">Hi Jordan,</span><div style="font-size:small"><br></div><div style="font-size:small">Thanks for the explanation - much appreciated.</div><div style="font-size:small"><br></div><div style="font-size:small">It&#39;s a shame stored properties can&#39;t be overridden, but I can see how there are issues around observers etc.</div><div style="font-size:small"><br></div><div style="font-size:small">For now I&#39;ve switched to a private backing property and a factory method, similar to what you suggested.</div><div style="font-size:small"><br></div><div style="font-size:small">John</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, 11 Jan 2018 at 18:51 Jordan Rose &lt;<a href="mailto:jordan_rose@apple.com">jordan_rose@apple.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">This isn’t supposed to be supported, and you get a warning for it in Swift 4.1 (see <a href="https://bugs.swift.org/browse/SR-6165" target="_blank">SR-6165</a>). I mentioned this in the fix:<div><br></div><div><blockquote type="cite">Arguably we could allow overriding with a stored property. The original concerns were that you could accidentally end up with extra storage you didn&#39;t need, and that observing accessors would behave differently based on whether or not the property was overriding. But there&#39;s at least no ambiguity for &#39;lazy&#39;, which can&#39;t have observing accessors today.<br></blockquote><br>If you want to get this behavior, you can make a <i>second</i> private lazy property, and override the public property with a getter that just forwards to the lazy property.</div><div><br></div><div>Sorry for the confusion!</div><div></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div>Jordan<br></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><div><div><blockquote type="cite"><div>On Jan 11, 2018, at 02:56, John Buckley via swift-users &lt;<a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a>&gt; wrote:</div><br class="m_-270645340190409470Apple-interchange-newline"></blockquote></div></div></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><div><div><blockquote type="cite"><div><div dir="ltr">I&#39;m interested to know if overriding a lazy stored property in a sub-class is recommended or not. For example:<div><br></div><div>class CustomSegue: NSStoryboardSegue {</div><div>    lazy var animator: CustomAnimator()</div><div><br></div><div>    override func prepare() {</div><div>         ....</div><div>    }</div><div>}</div><div><br></div><div>class CustomSlideRightSegue: CustomSegue {</div><div>     override lazy var animator: CustomAnimator(.slideRight)</div><div>}</div><div><br></div><div>This works fine and the compiler does not complain. However:</div><div><br></div><div>1. Why is overriding lazy stored properties supported, while overriding a non-lazy stored property is not.</div><div><br></div><div>2. Is this behaviour intended and/or recommended.</div><div><br></div><div>3. I realise you can achieve the same result by overriding init in the sub-class and assigning to a non-lazy property, however often this reduces clarity and introduces un-necessary boiler-plate code (especially if init takes a number of args).</div><div><br></div><div>Thanks!</div><div><br></div><div>John</div></div></div></blockquote></div></div></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><div><div><blockquote type="cite"><div>
_______________________________________________<br>swift-users mailing list<br><a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-users" target="_blank">https://lists.swift.org/mailman/listinfo/swift-users</a><br></div></blockquote></div></div></div></div></blockquote></div>