DIP proposal: Enum parameters

[Nicholas Wilson]

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.

Regarding Prior Art, this reminds me a lot of C++'s `auto` 
function parameters that make the function a template function 
without the need of the syntax overhead that comes with C++.
It also reminds me of SPIR-V specialisation constants, which 
serve a different purpose of late binding values for the 
optimiser.

Those are two incompatible meanings, and it is not entirely clear 
which one the DIP wants to be. I think the best option would be 
to have a static opSlice be something else and have enum 
parameters be values that must resolve at compile time.

This DIP makes no mention of what one can do with an enum 
parameter. In particular it would be very useful to be able to 
use CTFE with it, and do static assertions (e.g. check signatures 
of format strings). and (not that I'm sure there is any easy way 
to do it) being able to differentiate (and let the compiler know, 
probably more of a problem for DMD) if the intention is to reduce 
template bloat (in the case of format) or use the value as a 
specialisation constant.

> cf. a ref parameter only binds to lvalues

This is not the case, for C++ interop reasons (among others) 
`const ref` can bind rvalues.