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