[swift-users] Override Lazy Stored Property

[John Buckley]

Hi Jordan,

Thanks for the explanation - much appreciated.

It's a shame stored properties can't be overridden, but I can see how there
are issues around observers etc.

For now I've switched to a private backing property and a factory method,
similar to what you suggested.

John

On Thu, 11 Jan 2018 at 18:51 Jordan Rose <jordan_rose at apple.com> wrote:

> 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/20180112/556a8399/attachment.html>