DIP proposal: Enum parameters

[Quirin Schroll]

On Tuesday, 27 September 2022 at 14:39:58 UTC, TheGag96 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.
>
> So my first thought seeing this was that `enum` parameters 
> would bind to compile-time constants but don't incur extra 
> codegen for each value passed in, and `auto enum`, when used 
> once at least, would implicitly generate exactly two copies. 
> But given this, I don't think that's what you're saying:
>
>> In the function body (including contracts and constraints), an 
>> `enum` parameter’s value is a compile-time constant as if it 
>> were template value parameter. The same is true for `this` in 
>> an `enum` non-`static` member function body. The difference 
>> between `enum` parameters and template value parameters is 
>> only in calling syntax: `f!ct_value(args)` versus `f(ct_value, 
>> args)`.
>
> So the DIP exists purely to introduce a more unified calling 
> syntax?

Yes. If you boil it down to a short and vague sentence, you’re 
right.

It’s another way to get compile-time information into a function 
that is – notably – syntactically identical to passing run-time 
information into a function. This is on purpose so the function 
can potentially react to information passed this way or the other 
and in the compile-time case, on the information itself, and the 
user need not care at all.