UFCS & overloaded property getters/setters

Jonathan M Davis via Digitalmars-d digitalmars-d at puremagic.com
Fri Jun 13 10:53:38 PDT 2014


On Fri, 13 Jun 2014 09:39:04 -0700
"H. S. Teoh via Digitalmars-d" <digitalmars-d at puremagic.com> wrote:

> I'm not sure if this is a bug, or an anti-pattern, or what, but I ran
> into this issue yesterday:
>
>   class Base {
>       int propImpl;
>       final @property int prop() { return propImpl; }
>       @property void prop(int newVal) { propImpl = newVal; }
>
>       void someMethod() {
>           auto x = prop; // OK, calls Base.prop()
>           prop = x; // OK, calls Base.prop(int)
>       }
>   }
>
>   class Derived : Base {
>       override @property void prop(int newVal) {
>           super.prop(newVal);
>           doSomethingElse(newVal);
>       }
>
>       void someOtherMethod() {
>           auto x = prop; // NG - compile error ***
>           auto y = super.prop; // OK, calls Base.prop()
>           prop = x; // OK, calls Derived.prop()
>       }
>   }
>
> Basically, once the derived class overrides the property setter, the
> (un-overridden) base class getter somehow becomes shadowed as well,
> and references to .prop will cause a compile error saying that
> Derived.prop can't be called without parameters.
>
> So, what's going on here? Should this code be accepted? Is this a
> compiler / language bug? A deliberate @property limitation? Or just
> more evidence @property should be taken out the back and shot?

This is normal and has nothing to do with @property. When you override a
function in a derived class, you either have to override all its overloads in
the derived class or alias the base class symbols in the derived class, or all
the base class overloads which weren't overridden are hidden. I believe that
it's one of D's attempts to avoid function hijacking. And I believe that it is
discussed in the language docs somewhere.

- Jonathan M Davis


More information about the Digitalmars-d mailing list