View mode: basic / threaded / horizontal-split · Log in · Help
November 20, 2009
Re: Can we drop static struct initializers?
Yigal Chripun wrote:
> what about foreach_reverse ?

No love for foreach_reverse? <tear>
November 20, 2009
Re: Can we drop static struct initializers?
Bill Baxter wrote:
> Here's one thing I just found:
> struct constructors don't work at compile-time:
> 
> struct Struct
> {
>     this(int _n, float _x) {
>         n = _n; x = _x;
>     }
>     int n;
>     float x;
> }
> 
> enum A = Struct(1,2);
> 
> // Error: cannot evaluate ((Struct __ctmp1;
> // ) , __ctmp1).this(1,2F) at compile time
> 
> The C-style initializer works.
> static opCall works too.
> 
> But if that bug is fixed, then I can't think of a reason to have the
> classic C-style no-colons syntax.

It isn't a bug. You simply don't need constructors that progressively 
assign parameters to fields.

   Struct(1,2);

works just fine without that constructor being defined.
November 20, 2009
Re: Can we drop static struct initializers?
On Fri, Nov 20, 2009 at 3:34 PM, Walter Bright
<newshound1@digitalmars.com> wrote:
> Bill Baxter wrote:
>>
>> Here's one thing I just found:
>> struct constructors don't work at compile-time:
>>
>> struct Struct
>> {
>>    this(int _n, float _x) {
>>        n = _n; x = _x;
>>    }
>>    int n;
>>    float x;
>> }
>>
>> enum A = Struct(1,2);
>>
>> // Error: cannot evaluate ((Struct __ctmp1;
>> // ) , __ctmp1).this(1,2F) at compile time
>>
>> The C-style initializer works.
>> static opCall works too.
>>
>> But if that bug is fixed, then I can't think of a reason to have the
>> classic C-style no-colons syntax.
>
> It isn't a bug. You simply don't need constructors that progressively assign
> parameters to fields.
>
>   Struct(1,2);
>
> works just fine without that constructor being defined.

Right, but if you do define it (in order to do something extra upon
initialization -- validate inputs or what have you) then it no longer
works at compile time.

--bb
November 21, 2009
Re: Can we drop static struct initializers?
Bill Baxter wrote:
> Right, but if you do define it (in order to do something extra upon
> initialization -- validate inputs or what have you) then it no longer
> works at compile time.

Right, but the static initialization then shouldn't work, either.
November 21, 2009
Re: Can we drop static struct initializers?
On Fri, Nov 20, 2009 at 4:05 PM, Walter Bright
<newshound1@digitalmars.com> wrote:
> Bill Baxter wrote:
>>
>> Right, but if you do define it (in order to do something extra upon
>> initialization -- validate inputs or what have you) then it no longer
>> works at compile time.
>
> Right, but the static initialization then shouldn't work, either.

Why not?  It works if you use static opCall(int,int) instead of this(int,int).

--bb
November 21, 2009
Re: Can we drop static struct initializers?
Bill Baxter wrote:
> On Fri, Nov 20, 2009 at 3:34 PM, Walter Bright
> <newshound1@digitalmars.com> wrote:
>> Bill Baxter wrote:
>>> Here's one thing I just found:
>>> struct constructors don't work at compile-time:
>>>
>>> struct Struct
>>> {
>>>    this(int _n, float _x) {
>>>        n = _n; x = _x;
>>>    }
>>>    int n;
>>>    float x;
>>> }
>>>
>>> enum A = Struct(1,2);
>>>
>>> // Error: cannot evaluate ((Struct __ctmp1;
>>> // ) , __ctmp1).this(1,2F) at compile time
>>>
>>> The C-style initializer works.
>>> static opCall works too.
>>>
>>> But if that bug is fixed, then I can't think of a reason to have the
>>> classic C-style no-colons syntax.
>> It isn't a bug. You simply don't need constructors that progressively assign
>> parameters to fields.
>>
>>   Struct(1,2);
>>
>> works just fine without that constructor being defined.
> 
> Right, but if you do define it (in order to do something extra upon
> initialization -- validate inputs or what have you) then it no longer
> works at compile time.
> 
> --bb

This is where CTFE should come to save the day.

Andrei
November 21, 2009
Re: Can we drop static struct initializers?
Bill Baxter wrote:
> On Fri, Nov 20, 2009 at 4:05 PM, Walter Bright
> <newshound1@digitalmars.com> wrote:
>> Bill Baxter wrote:
>>> Right, but if you do define it (in order to do something extra upon
>>> initialization -- validate inputs or what have you) then it no longer
>>> works at compile time.
>> Right, but the static initialization then shouldn't work, either.
> 
> Why not?  It works if you use static opCall(int,int) instead of this(int,int).

Because if you need runtime execution to initialize, a back door to 
statically initialize it looks like a bug.
November 21, 2009
Re: Can we drop static struct initializers?
Walter Bright wrote:
> Bill Baxter wrote:
>> On Fri, Nov 20, 2009 at 4:05 PM, Walter Bright
>> <newshound1@digitalmars.com> wrote:
>>> Bill Baxter wrote:
>>>> Right, but if you do define it (in order to do something extra upon
>>>> initialization -- validate inputs or what have you) then it no longer
>>>> works at compile time.
>>> Right, but the static initialization then shouldn't work, either.
>>
>> Why not?  It works if you use static opCall(int,int) instead of 
>> this(int,int).
> 
> Because if you need runtime execution to initialize, a back door to 
> statically initialize it looks like a bug.

No, it's a known bug. The problem is that a constructor call A a(b); 
gets changed into   (A __a;, __a.opThis())

The scope of __a is whereever it's called from. In the case of

const int X = foo(A a);

__ is in global scope, so it's a static variable, and therefore can't be 
used in CTFE! But of course it's not a genuine static, it's just an 
artifact of the transformation.

Exactly the same problem happens with variadic arguments. And for pretty 
much the same reason, you get an ICE if you declare a struct with a 
constructor as a default function parameter.
I'm not sure, but it could be that int parameters also become shared 
variables?

One way to fix it might be to introduce a flag such that 
compiler-generated statics are marked so that they can distinguished 
from real statics.
November 21, 2009
Re: Can we drop static struct initializers?
On Sat, Nov 21, 2009 at 3:07 AM, retard <re@tard.com.invalid> wrote:
> Fri, 20 Nov 2009 17:06:44 -0300, Leandro Lucarella wrote:
>
>>> So, C-style arrays are gone, C-style struct initializers are gone,
>>
>> C-style comma operator is gone, ... no, wait. I'm dreaming =P
>
> It will never die. It's a perfect construct to be used in code generation.

Yes, but as has been point out many times, it doesn't need to occupy
such a plumb piece of syntactical real estate in order to be a useful
code gen construct.

--bb
November 21, 2009
Re: Can we drop static struct initializers?
On Fri, 20 Nov 2009 15:30:48 -0800, Walter Bright
<newshound1@digitalmars.com> wrote:

>Yigal Chripun wrote:
>> what about foreach_reverse ?
>
>No love for foreach_reverse? <tear>

And no mercy for opApply
1 2 3 4 5 6
Top | Discussion index | About this forum | D home