View mode: basic / threaded / horizontal-split · Log in · Help
May 30, 2012
Compile-time evaluation lost in alias this
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?
May 30, 2012
Re: Compile-time evaluation lost in alias this
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.
May 30, 2012
Re: Compile-time evaluation lost in alias this
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);
May 30, 2012
Re: Compile-time evaluation lost in alias this
...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.
May 30, 2012
Re: Compile-time evaluation lost in alias this
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.
May 30, 2012
Re: Compile-time evaluation lost in alias this
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
May 30, 2012
Re: Compile-time evaluation lost in alias this
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.
May 30, 2012
Re: Compile-time evaluation lost in alias this
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
May 30, 2012
Re: Compile-time evaluation lost in alias this
Thanks for a clear explanation. I filed a bug report:
http://d.puremagic.com/issues/show_bug.cgi?id=8169
May 30, 2012
Re: Compile-time evaluation lost in alias this
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
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home