bearophile <bearophileHUGS@lycos.com> wrote:
> Robert Jacques:
> 
>>> Seconded.  StaticIota is extremely useful for loop unrolling optimizations, e.g.:
>> 
>> vote++
> 
> vote--
> 
> StaticIota is not the good solution. I have explained why elsewhere: http://d.puremagic.com/issues/show_bug.cgi?id=4085
> 
> Bye,
> bearophile

vote += 2;

Who said staticIota is only used in static foreach? What if I want to
supply staticMap!(staticToString, staticIota!('a', 'z'+1)) as the default
argument of parameter names for 'naryFun'?

On Mon, 05 Sep 2011 19:49:43 +0200, Timon Gehr <timon.gehr@gmx.ch> wrote:

> On 09/05/2011 07:31 PM, Simen Kjaeraas wrote:
>> On Mon, 05 Sep 2011 13:05:23 +0200, bearophile
>> <bearophileHUGS@lycos.com> wrote:
>>
>>> Robert Jacques:
>>>
>>>> > Seconded. StaticIota is extremely useful for loop unrolling
>>>> optimizations, e.g.:
>>>>
>>>> vote++
>>>
>>> vote--
>>>
>>> StaticIota is not the good solution. I have explained why elsewhere:
>>> http://d.puremagic.com/issues/show_bug.cgi?id=4085
>>
>> Certainly we could sit in a corner and pray to almighty Walter that this be
>> implemented, when he's done with the things he wants to do with D. Oooor
>> - we
>> could add StaticIota to Phobos, bypass the problem, and live happily
>> ever after.
>>
>> Yes, static foreach would be nice, but the means to do what it would do,
>> are
>> easily implemented in the language as is.
>>
>
> That is some heavy C++ design style reasoning.

I disagree. I would heartily welcome static foreach, I'm only saying
that rather than wait for the perfect solution (which might never appear)
we should work with what we have.

-- 
  Simen

On 09/05/2011 08:19 PM, kenji hara wrote:
> 2011/9/6 Simen Kjaeraas<simen.kjaras@gmail.com>:
>> On Mon, 05 Sep 2011 13:05:23 +0200, bearophile<bearophileHUGS@lycos.com>
>> wrote:
>>
>>> Robert Jacques:
>>>
>>>>> Seconded.  StaticIota is extremely useful for loop unrolling
>>>>> optimizations, e.g.:
>>>>
>>>> vote++
>>>
>>> vote--
>>>
>>> StaticIota is not the good solution. I have explained why elsewhere:
>>> http://d.puremagic.com/issues/show_bug.cgi?id=4085
>>
>> Certainly we could sit in a corner and pray to almighty Walter that this be
>> implemented, when he's done with the things he wants to do with D. Oooor -
>> we
>> could add StaticIota to Phobos, bypass the problem, and live happily ever
>> after.
>>
>> Yes, static foreach would be nice, but the means to do what it would do, are
>> easily implemented in the language as is.
>
> Agreed to Simen. The foreach statement already has loop unrolling
> feature. To use it, we can pass a compile-time sequence (like
> TypeTuple) as its aggregator.
>
> I think it is clear language design, and not need more. Then we need staticIota.
>

static foreach is part of the design. The only reason it is not in the compiler (and we have the kludgy foreach that works on tuples) is because Walter experienced implementation difficulties.

How would you generate a number of declarations with the current foreach and StaticIota?

On 05.09.2011 21:55, Timon Gehr wrote:
>
> static foreach is part of the design. The only reason it is not in the compiler (and we have the kludgy foreach that works on tuples) is because Walter experienced implementation difficulties.
>

Before implementation somebody must precisely define static foreach, better to say static looping construct.

On 9/5/11 13:31 EDT, Simen Kjaeraas wrote:
> On Mon, 05 Sep 2011 13:05:23 +0200, bearophile
> <bearophileHUGS@lycos.com> wrote:
>
>> Robert Jacques:
>>
>>> > Seconded. StaticIota is extremely useful for loop unrolling
>>> optimizations, e.g.:
>>>
>>> vote++
>>
>> vote--
>>
>> StaticIota is not the good solution. I have explained why elsewhere:
>> http://d.puremagic.com/issues/show_bug.cgi?id=4085
>
> Certainly we could sit in a corner and pray to almighty Walter that this be
> implemented, when he's done with the things he wants to do with D. Oooor
> - we
> could add StaticIota to Phobos, bypass the problem, and live happily
> ever after.
>
> Yes, static foreach would be nice, but the means to do what it would do,
> are
> easily implemented in the language as is.

The problem is that StaticIota is not a replacement for static foreach due to scoping issues. We need a form of iteration that, just like static if, plants symbols in the current scope, not in a new scope. StaticIota is unable to help with that.

Andrei

On 09/05/2011 10:43 PM, zeljkog wrote:
> On 05.09.2011 21:55, Timon Gehr wrote:
>>
>> static foreach is part of the design. The only reason it is not in the
>> compiler (and we have the kludgy foreach that works on tuples) is
>> because Walter experienced implementation difficulties.
>>
>
> Before implementation somebody must precisely define static foreach,
> better to say static looping construct.

It works just like foreach, except that it does not introduce a new scope and can be used at module and aggregate scope.

Eg:

static foreach(x;0..5) {
    mixin("T!x var"~to!string(x)~";");
}

is equivalent to

T!0 var0;
T!1 var1;
T!2 var2;
T!3 var3;
T!4 var4;

The aggregate to loop over is evaluated at compile time:

int[] getAggregate(){return [1,2,3,];}
static foreach(x;getAggregate()) {
    pragma(msg,x);
}

writes during compilation:
1
2
3

Andrei Alexandrescu:

> We need a form of iteration that, just like static if, plants symbols in the current scope, not in a new scope. StaticIota is unable to help with that.

A good static foreach works outside any functions too (as static if), at global scope.

Bye,
bearophile

Simen Kjaeraas:

> Certainly we could sit in a corner and pray to almighty Walter that this be implemented,

Walter did find problems in trying to implement a *full* static foreach. Walter is intelligent, quite experienced, and knows the DMD codebase well, but he's just one person. So maybe if he explains here what those problems were, someone else will find a partial solution...

Bye,
bearophile

On 05.09.2011 23:06, Timon Gehr wrote:
>
> The aggregate to loop over is evaluated at compile time:
>
> int[] getAggregate(){return [1,2,3,];}
> static foreach(x;getAggregate()) {
> pragma(msg,x);
> }
>

Eh :)
For me the only compile time agregate is tuple.

We should talk about basic looping construct for compile time evolution.

On 09/06/2011 12:36 AM, zeljkog wrote:
> On 05.09.2011 23:06, Timon Gehr wrote:
>>
>> The aggregate to loop over is evaluated at compile time:
>>
>> int[] getAggregate(){return [1,2,3,];}
>> static foreach(x;getAggregate()) {
>> pragma(msg,x);
>> }
>>
>
> Eh :)
> For me the only compile time agregate is tuple.

foreach already works with any aggregate at compile time.

int[] getAggregate(){return [1,2,3,];}
mixin({
    string r;
    foreach(x;getAggregate()) r~="pragma(msg,"~to!string(x)~");";
    return r;
}());

What is your point?

>
> We should talk about basic looping construct for compile time evolution.
>

In CTFE you can use any looping construct you like.