DIP proposal: Enum parameters

[Quirin Schroll]

On Saturday, 24 September 2022 at 00:12:35 UTC, Timon Gehr wrote:
> Looks useful.

Thanks.

> - The author's name is spelled wrong.

Happens to the best. 😅

> - The description of `auto enum` makes it not fully clear if 
> the compiler attempts to interpret the argument with CTFE or 
> not to check whether it is a compile-time constant. Same 
> question about overloads. (Though for overloads I would expect 
> CTFE to be attempted, as in the first step it has to be 
> determined which overloads even match.)

Yes, I have to make this clear. CTFE *must* be attempted when 
binding to `auto enum`. It only becomes to non-`enum` if `enum` 
(without `auto`) would not be able to bind the argument. 
(Similarly, `auto ref` is required to bind as `ref` even if it 
could bind via copy.)

> - The special-case qualifier and storage class behavior is not 
> necessary, just make it behave like a normal `enum` variable.

I don’t really know what you mean exactly. Maybe this section:
> The `enum` storage class is incompatible with any other storage 
> classes except type constructors. Using them together is a 
> compile error. Type constructors are allowed, but have no 
> effect because compile-time values are `immutable` and for any 
> type constructor `qual` and every type `T`, we have 
> `qual(immutable T)` ≡ `immutable T`).

By the way, I’ve figured the explanation in the DIP is wrong. 
`enum` values are not immutable or effectively immutable. It 
appears that the semantics of `enum` currently make the value a 
literal for the first and second level of indirection. The other 
parts are mutable unless qualified, and do not count as mutable 
global state as far as `pure` is concerned. [Issue 
23375](https://issues.dlang.org/show_bug.cgi?id=23375)

I realized when answering to Paul Backus about the 
incompatibility with storage classes, in particular `scope`. I 
created some examples with indirections and found bugs.