Ary Borenszweig wrote:
> Lionello Lunesu wrote:
>>
>> "Brad Roberts" <bra...@bellevue.puremagic.com> wrote in message
>> news:alpine.deb.2.00.0903121755240.4...@bellevue.puremagic.com...
>>> That said, I don't think this really helps the desired usecase much.
>>> It's
>>> useful, don't get me wrong, but still requires code to build up the
>>> bi-directional translations. Or am I missing something? Seems to be
>>> happening to me a lot lately, so I'm very prepared to be wrong here too.
>>> :)
>>
>>
>> You're not wrong :)
>> The problem is that the foreach variable is not evaluatable to a
>> compile-time string. I don't know why, but I'll figure it out tonight.
>>
>> I've also managed to convert an enum to an AssocArrayLiteralExp* (with
>> the name/string as the key and the value/int as the value) but it
>> seems that it cannot be foreached at compile time, even if it's a
>> literal expression. But hell, I've spent about 1 hour browsing through
>> dmd's code, so I'm pretty sure it's possible with a little more research.
>
> Can you foreach at compile-time? I thought you could only do that in
> CTFE (or templates?). Maybe that's why it's not working. How do you do
> it to pragma msg the members of a struct?
>
> I remember someone proposed "static foreach" some time ago...
We have a sort-of static foreach. The trick is that the aggregate HAS
to be a tuple. When in doubt, you can always fall back on the following
construct:
template Tuple(T...)
{
alias T Tuple;
}
template Range(int n)
{
static if( n <= 0 )
alias Tuple!() Range;
else
alias Tuple!(Range!(n-1), n-1) Range;
}
void blah()
{
// Note that static foreach ONLY works inside a function
foreach( i ; Range!(n) )
{
// do stuff with i, which should be a const int
}
}
There have been times when directly accessing some CT construct would
make the compiler choke, but going via an index worked fine.
-- Daniel
