Philippe Sigaud wrote:
That beats hell out of my clumsy templates :)
Your templates are not clumsy, it's typically the way some other PL
would process lists/arrays. I used to write a lot of these. But 6 months
ago, CTFE got seven-leagues boots and right now it's much easier on the
eye to use CT functions.
Thanks for friendly shoulder tap :)
I think I just need to get accustomed with CTFE. I mostly work in C++,
and it's templates (much inspired by Andrei's C++ publications as well
as Loki, by the way) are telling on me. I constantly tend to forget
there are so many constructs in D I can use at compile time without worry.
When I was on the way to my initial solutions I was under strong
impression that T[N] func() won't work. Now I see that was because I
didn't bother to fully understand how arrays are returned from
functions. I got it now, so thanks a lot again!
There used to be a time, maybe not 18 months ago where returning static
arrays from functions was not possible, IIRC..
This may have something to do with my assumptions. I haven't tried D
much since when shared was introduced (don't remember how long ago it was).
Right now, I think you
can use them with no problem. Maybe someone well-versed in optimization
will tell us it's not a good idea, I don't know.
Well, as you've said yourself, if it works... :)
PS. I'm not sure as to where to post this, but after I tried your
solution I've noticed one interesting (or rather strange) thing:
struct S(T,size_t N)
{
T[N] arr;
int foo; // type doesn't seem to matter here,
// taking int for clarity
static immutable S C1 = { initializeWith!(T,N)(0) 5 };
// Note there is no comma after first initializer ^
}
This actually compiles and works, though I have an impression that
syntax error is in order. Putting in second array and attempting similar
initialization without commas leads to one. I've only tried it with
Windows 2.048, though I think the front end would eat this on Linux too.
Is this valid, already known or I should report this?
