An enum only exists at compile-time, and does not occupy any
space. Each time it's referenced, a new instance of the value
is created. Why is that? Seems like a waste of resources to the compiler.

On Monday, 1 February 2021 at 09:40:20 UTC, Per Nordlöw wrote:
> An enum only exists at compile-time, and does not occupy any
> space. Each time it's referenced, a new instance of the value
> is created. Why is that? Seems like a waste of resources to the compiler.

It makes perfect sense for numeric values, strings, characters and similar values. Why waste extra space on a variable if it's not needed?

If you don't want a new instance, then don't use `enum`. Use `immutable` instead.

--
/Jacob Carlborg

On Monday, 1 February 2021 at 09:52:07 UTC, Jacob Carlborg wrote:
> If you don't want a new instance, then don't use `enum`. Use `immutable` instead.

Agreed. My question is why does an `enum` require an extra instance from a compiler architecture point of view? Do all compilers handle compile-time enum instances in that way?

On Monday, 1 February 2021 at 10:08:21 UTC, Per Nordlöw wrote:

> Agreed. My question is why does an `enum` require an extra instance from a compiler architecture point of view? Do all compilers handle compile-time enum instances in that way?

There is no "extra" instance because there's no single instance of an enum value. They have no address. When you use one, it's just as if you were writing the literal instead of the enum name. In other words:

enum ea = [1, 2, 3];
auto a0 = ea;
auto a1 = ea;

is identical to this:

auto a0 = [1, 2, 3];
auto a1 = [1, 2, 3];

It's purely a compile-time construct. Essentially just an alias for a literal.

On Monday, 1 February 2021 at 10:24:59 UTC, Mike Parker wrote:
> There is no "extra" instance because there's no single instance of an enum value. They have no address. When you use one, it's just as if you were writing the literal instead of the enum name. In other words:
>
> enum ea = [1, 2, 3];
> auto a0 = ea;
> auto a1 = ea;
>
> is identical to this:
>
> auto a0 = [1, 2, 3];
> auto a1 = [1, 2, 3];

Ok, so then my follow-up question becomes, does the right hand sides of these two assignment share the same AST node? If not, why?

On Monday, 1 February 2021 at 11:37:49 UTC, Per Nordlöw wrote:
> Ok, so then my follow-up question becomes, does the right hand sides of these two assignment share the same AST node? If not, why?

Because such a shared AST node could be potentially mutated in different ways in different contexts during its passes?

On Monday, 1 February 2021 at 09:40:20 UTC, Per Nordlöw wrote:
> An enum only exists at compile-time, and does not occupy any
> space. Each time it's referenced, a new instance of the value
> is created. Why is that?

Short answer: An enum is a literal you can refer to by name. That's my mind-model for an enum.

Long answer: If you use the literal "abc" twice, because it's underlying type is immutable (string == immutable(char)[]), the compiler can elide multiple allocations. But ['a','b','c'] has to be allocated each use. Basically, it lowers to a `new char[](3)` plus initialization.
It is completely irrelevant how the value has been determined.

On Monday, 1 February 2021 at 20:00:26 UTC, Q. Schroll wrote:
> On Monday, 1 February 2021 at 09:40:20 UTC, Per Nordlöw wrote:
>> An enum only exists at compile-time, and does not occupy any
>> space. Each time it's referenced, a new instance of the value
>> is created. Why is that?
>
> Short answer: An enum is a literal you can refer to by name. That's my mind-model for an enum.

I forgot to mention: An enum can have a precise type. As a stupid example, there are no first-class literals of type short or byte. But you can easily have short or byte enums. Also, the empty slice [] is typed void[] if you ask typeof([]); but an empty enum can be typed as any T[].

On Monday, 1 February 2021 at 11:39:26 UTC, Per Nordlöw wrote:
> On Monday, 1 February 2021 at 11:37:49 UTC, Per Nordlöw wrote:
>> Ok, so then my follow-up question becomes, does the right hand sides of these two assignment share the same AST node? If not, why?
>
> Because such a shared AST node could be potentially mutated in different ways in different contexts during its passes?

The spec says nothing about AST nodes. You can ask what DMD does (I don't know), but technically speaking, ASTs are an implementation detail of a compiler. A compiler need not have ASTs at all to follow the spec (unless the spec demands ASTs to exist, which I think it does not do). A compiler can change its AST nodes to a different yet equivalent representation without issue (unless the spec demands ASTs to exist and be of a certain form, which I think it does not do).