---
enum X = [1,2,3];
void main()
{
assert( X.ptr is X.ptr);
assert( X is X );
}
---
Both asserts fail at runtime, because they are equivalent to
assert( [1,2,3].ptr is [1,2,3].ptr);
assert( [1,2,3] is [1,2,3] );
It would be OK for X to be an int[3] array, but not a slice.
Fundamentally, a reference enum type doesn't make sense. They can't have an address.
This is the root cause of bug 4397.
Comment #1 by bearophile_hugs — 2013-04-18T02:43:05Z
This bug report seems for associative arrays too, then.
This bug report is about an old and significant problem of D. Disallowing all enum reference types seems a little harsh, but I don't know if there are better solutions.
One problem with this proposal is that there is probably some D code around that uses enum dynamic arrays and associative arrays (I have stopped using them in my code since some time), and this proposal will break that code.
One advantage of disallowing enum dynamic arrays is that this avoids a performance trap, because they get rebuild at every usage point, and this in the middle of a loop is a waste of time.
Comment #2 by andrej.mitrovich — 2013-04-18T07:15:52Z
If we're going to do this we might as well introduce it in 2.063, since this release will have breaking changes related to this.
For example const/immutable fields with initializers will no longer be implicitly static, and people might end up changing them to manifest constants. If they were l-value initializers it's going to cause further problems when this issue is implemented (hence why it should be done sooner rather than later to avoid fixing code two times).
Comment #3 by yebblies — 2013-11-22T05:08:49Z
(In reply to comment #2)
> If we're going to do this we might as well introduce it in 2.063, since this
> release will have breaking changes related to this.
>
I don't want to do this until issue 6238 is fixed.
Comment #4 by robert.schadek — 2024-12-13T18:06:12Z