View mode: basic / threaded / horizontal-split · Log in · Help
October 25, 2007
Non compile time evaluation for initializers
Is there a good reason why the compiler does not allow non-CTFE initializers 
for non-const variables?

For instance, this does not work:

Logger log = Log.getLogger("test");

but this does:

Logger log;
static this()
{
  log = Log.getLogger("test");
}

But why is it necessary to prevent the first from compiling to the 
equivalent of the second?  As far as I'm concerned, it's OK if it doesn't 
evaluate at compile time.  And it's much more convenient to write the first 
version when you are setting up global or static variables instead of using 
the static this() form.  In my mind, CTFE is a form of optimization, one 
which I can live without if it's not possible, but I still want to be able 
to compile :)

-Steve
October 26, 2007
Re: Non compile time evaluation for initializers
"Steven Schveighoffer" <schveiguy@yahoo.com> wrote in message 
news:ffquc2$2kjg$1@digitalmars.com...
> Is there a good reason why the compiler does not allow non-CTFE 
> initializers for non-const variables?
>
> For instance, this does not work:
>
> Logger log = Log.getLogger("test");
>
> but this does:
>
> Logger log;
> static this()
> {
>   log = Log.getLogger("test");
> }

I agree.  Java and C# allow this, and I think it fits in very nicely with 
the existing static constructors.  Since you can have multiple static 
constructors in a module which are just executed in lexical order, a static 
variable being initialized with a non-compile-time initializer could just be 
rewritten as a declaration + 1-line static constructor.  Basically, your 
first snippet would be converted into your second.
October 26, 2007
Re: Non compile time evaluation for initializers
On 10/25/07, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> Is there a good reason why the compiler does not allow non-CTFE initializers
> for non-const variables?

So you're saying that, in general, if

   X x = y;

won't compile, then the compiler should rewrite it as

   X x;
   static this
   {
       x = y;
   }

Makes sense to me!
October 26, 2007
Re: Non compile time evaluation for initializers
Janice Caron wrote:
> On 10/25/07, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
>> Is there a good reason why the compiler does not allow non-CTFE initializers
>> for non-const variables?
> 
> So you're saying that, in general, if
> 
>     X x = y;
> 
> won't compile, then the compiler should rewrite it as
> 
>     X x;
>     static this
>     {
>         x = y;
>     }
> 
> Makes sense to me!

I think that's only the case for X x being static in the first place.
So

  static X x = y;

is rewritten

  static X x;
  static this {
      x = y;
  }

For class members I guess you might have the non-static initializers 
turn into some hidden extra work done just before the class's this() 
constructor.

I don't know if it's a good plan or not, but it would certainly be a lot 
nicer to be able to do:

class x
{
   int[] buffer = new int[128];
   ...
}

instead of:

class x
{
   int[] buffer;

   this() {
      buffer = new int[128];
   }
   this(Arg a) {
      this();
   }
   this(OtherArg a) {
      this();
   }
}

I seem to recall that Java allows that.

--bb
October 26, 2007
Re: Non compile time evaluation for initializers
Bill Baxter wrote:
> Janice Caron wrote:
>> On 10/25/07, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
>>> Is there a good reason why the compiler does not allow non-CTFE 
>>> initializers
>>> for non-const variables?
>>
>> So you're saying that, in general, if
>>
>>     X x = y;
>>
>> won't compile, then the compiler should rewrite it as
>>
>>     X x;
>>     static this
>>     {
>>         x = y;
>>     }
>>
>> Makes sense to me!
> 
> I think that's only the case for X x being static in the first place.
> So
> 
>   static X x = y;
> 
> is rewritten
> 
>   static X x;
>   static this {
>       x = y;
>   }

Ignore that part.

I think I was thinking about class X x being a class member.
so
class Foo {
   static X x = y;
}
becomes
class Foo {
   static X x;
}
static this {
    Foo.x = y;
}

--bb
October 26, 2007
Re: Non compile time evaluation for initializers
Janice Caron wrote:
> On 10/25/07, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
>> Is there a good reason why the compiler does not allow non-CTFE initializers
>> for non-const variables?
> 
> So you're saying that, in general, if
> 
>     X x = y;
> 
> won't compile, then the compiler should rewrite it as
> 
>     X x;
>     static this
>     {
>         x = y;
>     }
> 
> Makes sense to me!

Suppose this is implemented, then how can you achieve constant folding 
with CTFE in initializers? Since it is not a compile time context 
anymore, all functions that substitue y will be evaluated at runtime.
October 26, 2007
Re: Non compile time evaluation for initializers
Lutger wrote:
> Janice Caron wrote:
...
> Suppose this is implemented, then how can you achieve constant folding 
> with CTFE in initializers? Since it is not a compile time context 
> anymore, all functions that substitue y will be evaluated at runtime.

Nevermind, I responded too soon and overlooked the proviso that it's 
only rewritten when it doesn't compile, sorry.
October 26, 2007
Re: Non compile time evaluation for initializers
On Fri, 26 Oct 2007 10:52:25 +0200, Lutger
<lutger.blijdestijn@gmail.com> wrote:

>Lutger wrote:
>> Janice Caron wrote:
>...
>> Suppose this is implemented, then how can you achieve constant folding 
>> with CTFE in initializers? Since it is not a compile time context 
>> anymore, all functions that substitue y will be evaluated at runtime.
>
>Nevermind, I responded too soon and overlooked the proviso that it's 
>only rewritten when it doesn't compile, sorry.

Then if a compile time function is messed up in a way that makes it
unevaluatable at compile time, it would be silently used at run-time,
which is not desired?
October 26, 2007
Re: Non compile time evaluation for initializers
Max Samukha wrote:
> On Fri, 26 Oct 2007 10:52:25 +0200, Lutger
> <lutger.blijdestijn@gmail.com> wrote:
> 
>> Lutger wrote:
>>> Janice Caron wrote:
>> ...
>>> Suppose this is implemented, then how can you achieve constant folding 
>>> with CTFE in initializers? Since it is not a compile time context 
>>> anymore, all functions that substitue y will be evaluated at runtime.
>> Nevermind, I responded too soon and overlooked the proviso that it's 
>> only rewritten when it doesn't compile, sorry.
> 
> Then if a compile time function is messed up in a way that makes it
> unevaluatable at compile time, it would be silently used at run-time,
> which is not desired?

There are plenty of other ways to force compile-time evaluation. I use

const int x = ctfeFunction();

much more than

// global namespace
int x = ctfeFunction();


I wouldn't have any objection to keeping const meaning ctfe-evaluated, 
but global non-consts may be postponed till runtime.


  -- Reiner
October 26, 2007
Re: Non compile time evaluation for initializers
On Fri, 26 Oct 2007 22:47:02 +1000, Reiner Pope <some@address.com>
wrote:

>There are plenty of other ways to force compile-time evaluation. I use
>
>const int x = ctfeFunction();
>
>much more than
>
>// global namespace
>int x = ctfeFunction();
>
>
>I wouldn't have any objection to keeping const meaning ctfe-evaluated, 
>but global non-consts may be postponed till runtime.
>
>
>   -- Reiner

Agree
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home