DIP proposal: Enum parameters

Quirin Schroll qs.il.paperinik at gmail.com
Fri Sep 23 16:44:05 UTC 2022


On Friday, 23 September 2022 at 16:17:01 UTC, ryuukk_ wrote:
> On Friday, 23 September 2022 at 15:41:21 UTC, Quirin Schroll 
> wrote:
>> Read the draft here: 
>> https://github.com/Bolpat/DIPs/blob/EnumParameters/DIPs/1NNN-QFS.md
>>
>> Feedback is welcome.
>
> I use ``enum`` a lot in my code base, and i think the name of 
> that keyword for that usecase is very wrong, it conveys the 
> wrong intention

If you thought about `enum c = val;`, then we simply disagree 
about the intention.
If you thought about `enum { ... }` or `enum Name { ... }`, then 
you’re right, but isn’t the `enum` keyword used quite (if not 
even more) frequently like this?
```d
enum constant = value;
enum empty = false; // infinite ranges use this
```

Semantically, `enum c = val;` is not exactly sugar for `enum { c 
= val }`, because `enum c(T) = val!T;` works, but no equivalent 
(not even with explicit `template`) exists for `enum {}`. They 
are quite obviously different conceptually. Single `enum` is 
exactly what `comptime` would express: A compile-time only value, 
or (as I call it in my mind) a named literal (to better 
understand why an `enum` with slice type always allocates).

> ``enum`` is supposed to be an enumeration, not a _ for compile 
> time usecase, in fact, ``comptime`` is a better name, so i 
> personally would love if it was changed to that, if that's 
> possible.

It probably must be an existing keyword. `comptime` would be 
possible as a contextual keyword, something Walter opposes. 
`static` is the only other candidate. I’ve looked through the 
whole [list of 
keywords](https://dlang.org/spec/lex.html#keywords).


More information about the Digitalmars-d mailing list