Yigal Chripun wrote:
> what about foreach_reverse ?

No love for foreach_reverse? <tear>

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.

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

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.

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

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

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.

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.

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

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