[swift-users] Override Lazy Stored Property

[Jordan Rose]

This isn’t supposed to be supported, and you get a warning for it in Swift 4.1 (see SR-6165 <https://bugs.swift.org/browse/SR-6165>). I mentioned this in the fix:

> Arguably we could allow overriding with a stored property. The original concerns were that you could accidentally end up with extra storage you didn't need, and that observing accessors would behave differently based on whether or not the property was overriding. But there's at least no ambiguity for 'lazy', which can't have observing accessors today.

If you want to get this behavior, you can make a second private lazy property, and override the public property with a getter that just forwards to the lazy property.

Sorry for the confusion!
Jordan


> On Jan 11, 2018, at 02:56, John Buckley via swift-users <swift-users at swift.org> wrote:
> 
> I'm interested to know if overriding a lazy stored property in a sub-class is recommended or not. For example:
> 
> class CustomSegue: NSStoryboardSegue {
>     lazy var animator: CustomAnimator()
> 
>     override func prepare() {
>          ....
>     }
> }
> 
> class CustomSlideRightSegue: CustomSegue {
>      override lazy var animator: CustomAnimator(.slideRight)
> }
> 
> This works fine and the compiler does not complain. However:
> 
> 1. Why is overriding lazy stored properties supported, while overriding a non-lazy stored property is not.
> 
> 2. Is this behaviour intended and/or recommended.
> 
> 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).
> 
> Thanks!
> 
> John
> _______________________________________________
> swift-users mailing list
> swift-users at swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20180111/b03d3dfd/attachment.html>