struct ValueImpl
{
    static immutable(int) getValue()
    {
        return 42;
    }
}

struct ValueUser
{
    ValueImpl m_valueImpl;
    alias m_valueImpl this;
}

void main(string[] args)
{
    static assert(ValueImpl.getValue() == 42);
    static assert(ValueUser.getValue() == 42); // (1)
}

(1) Doesn't compile. Error: variable m_valueImpl cannot be read at compile time

To use alias this for composition, it would be nice if the compile-time evaluable members of the aliased object would remain compile-time evaluable even when used through an alias. Is the current behavior defined by the language or is it due to the compiler (DMD) implementation?

Le 30/05/2012 10:58, Tommi a écrit :
> struct ValueImpl
> {
> static immutable(int) getValue()
> {
> return 42;
> }
> }
>
> struct ValueUser
> {
> ValueImpl m_valueImpl;
> alias m_valueImpl this;
> }
>
> void main(string[] args)
> {
> static assert(ValueImpl.getValue() == 42);
> static assert(ValueUser.getValue() == 42); // (1)
> }
>
> (1) Doesn't compile. Error: variable m_valueImpl cannot be read at
> compile time
>
> To use alias this for composition, it would be nice if the compile-time
> evaluable members of the aliased object would remain compile-time
> evaluable even when used through an alias. Is the current behavior
> defined by the language or is it due to the compiler (DMD) implementation?

m_valueImpl isn't static and ValueUser not instantiated. I wouldn't expect this to compile at all, CTFE or not.

Like I said it doesn't compile because it can't do CTFE. But remove static in front of the second assert and it compiles (and works also during runtime):

assert(ValueUser.getValue() == 42);

...and that's what I would expect, if the purpose of alias this is to bring all the functionality from one type to another. Just like inheritance, but not quite.

Le 30/05/2012 14:43, Tommi a écrit :
> ...and that's what I would expect, if the purpose of alias this is to
> bring all the functionality from one type to another. Just like
> inheritance, but not quite.

Except your are not aliasing the type but an instance.

2012/5/30 Tommi <tommitissari@hotmail.com>:
> struct ValueImpl
> {
>    static immutable(int) getValue()
>    {
>        return 42;
>    }
> }
>
> struct ValueUser
> {
>    ValueImpl m_valueImpl;
>    alias m_valueImpl this;
> }
>
> void main(string[] args)
> {
>    static assert(ValueImpl.getValue() == 42);
>    static assert(ValueUser.getValue() == 42); // (1)
> }
>
> (1) Doesn't compile. Error: variable m_valueImpl cannot be read at compile
> time
>
> To use alias this for composition, it would be nice if the compile-time evaluable members of the aliased object would remain compile-time evaluable even when used through an alias. Is the current behavior defined by the language or is it due to the compiler (DMD) implementation?

Looks like a bug.

ValueUser.getValue() is translated to ValueUser.m_valueImpl.getValue()
with alias this resolution. In here:
1. ValueUser.m_valueImpl is a valid expression. It means just a symbol
of variable which declared in ValueUser struct.
2. ValueUser.m_valueImpl is only used for overload resolution of
calling getValue() and getValue is static member function, then it is
*never* evaluated even in run-time.

Please file a report about it in bugzilla.

Kenji Hara

On Wednesday, 30 May 2012 at 15:04:40 UTC, kenji hara wrote:
> Looks like a bug.
>
> ValueUser.getValue() is translated to ValueUser.m_valueImpl.getValue()
> with alias this resolution. In here:
> 1. ValueUser.m_valueImpl is a valid expression. It means just a symbol
> of variable which declared in ValueUser struct.
> 2. ValueUser.m_valueImpl is only used for overload resolution of
> calling getValue() and getValue is static member function, then it is
> *never* evaluated even in run-time.
>
> Please file a report about it in bugzilla.
>
> Kenji Hara

Sorry, I'm not sure what you mean. Which one of the following is a bug?

1) The fact that ValueUser.getValue() can't be evaluated at compile time
2) The fact that ValueUser.getValue() compiles and can be evaluated at runtime

I'm very new to the language. Just finished reading the book and I'm testing things out.

2012/5/31 Tommi <tommitissari@hotmail.com>:
> On Wednesday, 30 May 2012 at 15:04:40 UTC, kenji hara wrote:
>>
>> Looks like a bug.
>>
>> ValueUser.getValue() is translated to ValueUser.m_valueImpl.getValue()
>> with alias this resolution. In here:
>> 1. ValueUser.m_valueImpl is a valid expression. It means just a symbol
>> of variable which declared in ValueUser struct.
>> 2. ValueUser.m_valueImpl is only used for overload resolution of
>> calling getValue() and getValue is static member function, then it is
>> *never* evaluated even in run-time.
>>
>> Please file a report about it in bugzilla.
>>
>> Kenji Hara
>
>
> Sorry, I'm not sure what you mean. Which one of the following is a bug?
>
> 1) The fact that ValueUser.getValue() can't be evaluated at compile time
> 2) The fact that ValueUser.getValue() compiles and can be evaluated at
> runtime
>
> I'm very new to the language. Just finished reading the book and I'm testing things out.

Sorry for my poor English.
I'd like to say that ValueUser.getValue() should be evaluated at
compile time and runtime.

First, we cannot evaluate ValueUser.m_valueImpl in compile time, but
can *use* it in compile time.
This is a case, using it in typeof expression.

  static assert(is(typeof(ValueUser.m_valueImpl) == ValueImpl));

Type comparison is compile time operation, then this works.

Next, In the expression ValueUser.m_valueImpl.getValue() (equals to
ValueUser.getValue()), ValueUser.m_valueImpl is just used to specify
where the static function getValue is declared. We can rewrite it like
as:

  typeof(ValueUser.m_valueImpl).getValue()

So ValueUser.m_valueImpl is used in compile time, but not evaluated.

Therefore original error message is wrong because compiler should not try to evaluate ValueUser.m_valueImpl in compile time.

Kenji Hara

Thanks for a clear explanation. I filed a bug report:
http://d.puremagic.com/issues/show_bug.cgi?id=8169

2012/5/31 Tommi <tommitissari@hotmail.com>:
> Thanks for a clear explanation. I filed a bug report: http://d.puremagic.com/issues/show_bug.cgi?id=8169

OK. I've posted a pull request for bug 8169. https://github.com/D-Programming-Language/dmd/pull/971

Kenji Hara