Jump to page: 1 2
Thread overview
Non compile time evaluation for initializers
Oct 26, 2007
Janice Caron
Oct 26, 2007
Bill Baxter
Oct 26, 2007
Bill Baxter
Oct 26, 2007
Lutger
Oct 26, 2007
Lutger
Oct 26, 2007
Max Samukha
Oct 26, 2007
Reiner Pope
Oct 26, 2007
Max Samukha
Oct 26, 2007
Lutger
Oct 26, 2007
Max Samukha
October 25, 2007
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
"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
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
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
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
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
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
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
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
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