Comment #0 by verylonglogin.reg — 2013-06-04T08:54:43Z
This is necessary if you don't want to branch a templated function in static array case and just treat everything as a flat static array (i.e. both T and T[1][1] become T[1]):
---
ref f(ref int i)
{
return *cast(int[1]*) &i;
}
void g()
{
int i;
f(i)[0] = 5;
assert(i == 5);
}
static assert((g(), true));
---
Comment #1 by clugdbug — 2013-06-18T00:31:47Z
Supporting this would create a *huge* number of corner cases.
For example, CTFE strictly enforces C pointer arithmetic.
int b;
int * p = &b;
++p; // illegal, can only do pointer arithmetic on pointers to arrays
int[1] n;
int *q = &n[0];
++q; // ok, one past the end of an array is explicitly legal
I'm not sure if that cast leads to well-defined behaviour in C. I suspect that after the cast, it might not be a genuine array.
I think a 16bit C compiler could legally put b at location 0xFFFC, then after ++p, p would be 0. Which could never happen with a proper array.
Of course all this stuff could be implemented, but sticking to C rules makes things very much easier, because it eliminates so many of these nasty cases.
Comment #2 by verylonglogin.reg — 2013-06-18T01:24:11Z
(In reply to comment #1)
> I suspect that after the cast, it might not be a genuine array.
I like the idea to not create genuine array here. Just a restricted array for e.g. `foreach`.
Comment #3 by clugdbug — 2013-07-04T01:23:30Z
(In reply to comment #2)
> (In reply to comment #1)
> > I suspect that after the cast, it might not be a genuine array.
>
> I like the idea to not create genuine array here. Just a restricted array for
> e.g. `foreach`.
Hmmm, I don't know how to do that. This kind of feature is practically guaranteed to fail, it creates dozens of weird special cases (and they would all be subtle wrong-code bugs).
Comment #4 by robert.schadek — 2024-12-13T18:07:40Z