Troubles with immutable arrays
Don Clugston
dac at nospam.com
Wed Jul 25 03:59:37 PDT 2012
On 23/07/12 15:29, bearophile wrote:
> After a discussion in D.learn started by someone else, after a
> suggestion of mine Timon Gehr has added a bug report:
>
> http://d.puremagic.com/issues/show_bug.cgi?id=8400
>
> But the bug was fixed in the opposite way of what I was thinking.
>
> The problem was that the length of global immutable arrays arrays is
> seen as a compile-time constant.
> Instead of fixing that, Issue 8400 has done the opposite, now even the
> lenght of local immutable arrays is seen sometimes as a compile-time
> constant, and example:
Sorry bearophile, I completely disagree with this post.
Currently, when a compile time value is required, CTFE is attempted. If
it fails, an error message is generated.
You are asking for a corner case to be introduced. Under certain
circumstances (which aren't clearly defined), you want CTFE to *not* be
attempted.
> immutable int[] A = foo(5);
> int[A.length] B;
> This code too compiles, so A is sometimes computed at run-time and
> sometimes at compile-time:
immutable int[] A = foo(n);
> Now immutable arrays are sometimes seen as enums.
That is not correct, an immutable array is always different to an enum.
For example, an enum is simply a manifest constant, and does not have an
address. An immutable array always has an address.
> I think this is a
> problem. I think in D compile-time is run only if it's evaluated in a
> context where compile-time values are required. But now the situation is
> more muddy, because knowing n at compile-time is not a way to ask A to
> be computed at compile-time.
The only consequence is that if you don't require it at compile time, a
particular optimization might not happen. There is no change to semantics.
> Another problem is that compile-time arrays in many situations are not
> efficient, they gets copied every time you use them, and I think that
> __d_arrayliteralTX performs a heap allocation. So now both enum and
> immutable arrays perform heap allocations every time you use them, but
> only in some situations.
That's the famous bug 2356, which is completely irrelevant to this
situation.
> I think this is a messy situation, I think the fix for bug 8400 should
> be undone, and I think Issue 8400 should be fixed the other way, turning
> global immutable arrays too into run-time entities.
Did you even know that initializers of global variables, including
arrays, including even mutable arrays, are ALWAYS CTFE'd?
More information about the Digitalmars-d
mailing list