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@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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
