struct S {
    int value() {
    	return 1;
    }
}

class Base {
    S s;
    alias s this;
}

class Derived : Base {
    void func() {
        int i = value();
    }
}

Fails with "main.d(14): Error: undefined identifier value".
Explicitly casting this to Base works:

    void func() {
        int i = (cast(Base)this).value();
    }

Is this intended or a bug?

On 03/26/2013 04:58 PM, Henning Pohl wrote:
> struct S {
> int value() {
> return 1;
> }
> }
>
> class Base {
> S s;
> alias s this;
> }
>
> class Derived : Base {
> void func() {
> int i = value();
> }
> }
>
> Fails with "main.d(14): Error: undefined identifier value".
> Explicitly casting this to Base works:
>
> void func() {
> int i = (cast(Base)this).value();
> }
>
> Is this intended or a bug?

Since alias this is for implicit conversions, it should be effective only when Base is used as an S. It is not obvious in the previous code that the programmer really wanted that.

I like the current behavior. I wonder what others think.

Also, this works as well:

        int i = super.value();

Ali

Henning Pohl:

> class Base {
>     S s;
>     alias s this;
> }

"alias this" is meant to be used in structs.

Bye,
bearophile

> "alias this" is meant to be used in structs.

On the other hand, unless the compiler refuses to compile a class with an alias this, it should behave meaningfully.

Bye,
bearophile

On Tuesday, March 26, 2013 17:24:20 Ali Çehreli wrote:
> On 03/26/2013 04:58 PM, Henning Pohl wrote:
> > struct S {
> > int value() {
> > return 1;
> > }
> > }
> > 
> > class Base {
> > S s;
> > alias s this;
> > }
> > 
> > class Derived : Base {
> > void func() {
> > int i = value();
> > }
> > }
> > 
> > Fails with "main.d(14): Error: undefined identifier value".
> > Explicitly casting this to Base works:
> > 
> > void func() {
> > int i = (cast(Base)this).value();
> > }
> > 
> > Is this intended or a bug?
> 
> Since alias this is for implicit conversions, it should be effective only when Base is used as an S. It is not obvious in the previous code that the programmer really wanted that.
> 
> I like the current behavior. I wonder what others think.

We should be extremely careful with implicit conversions. They can be useful, but it makes it _very_ easy to cause bugs (particularly with regards to templates where it can easily become the case that something passes a template constraint due to an implicit conversion but fails to actually work with the function).

I don't know what the intended behavior here is, but since we already have cases like having to alias base class functions in derived classes when they were overloaded or not be able to call the base class overload, it doesn't surprise me at all that it would work this way.

- Jonathan M Davis