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