DIP proposal: Enum parameters

[jmh530]

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.

It might be good to start with a simple example. For instance, 
suppose we have two functions:

```d
void foo(int x) { //do something }
void foo(int x)() { //do something }
```

We can call `foo` like `foo(x)` or `foo!x` currently. In the 
first call, `x` can be a runtime variable or an enum. If `x` is 
an enum, then CTFE and compiler optimizations might simplify the 
resulting code significantly (though it's not always clear how 
much it will do that). In the second version, each `x` would 
generate a new function, resulting in template bloat, but at 
least as fast as the enum version and potentially simpler code.

You propose to add
```d
void bar(enum int x) { //do something }
```
and
```d
void bar(auto enum int x) { //do something }
```

My reading of the DIP is that the first `bar` is equivalent to 
the second `foo` (with template value parameters). The second 
`bar` would be like automatically including an overload for `void 
bar(int x) {}` along with the first one. So in this sense, you 
can call `bar(x)` where `x` is a runtime variable or a template 
value parameter.

However, as others have pointed out, what if `x` is an enum and 
you don't intend to use it like a template value parameter. This 
results in unnecessary template bloat. So I'm sympathetic to the 
argument that this should only work for `enums`. It limits the 
usefulness of this feature, but might be a bit more consistent 
with the language. The question would be whether that will work 
for your use case with respect to `opIndex` etc.

In order to better unify template value parameters with normal 
function calls, it might make more sense to borrow from zig's 
approach of first class types (though I wouldn't use that as an 
excuse to get rid of the D template syntax, just as an addition 
to).

There are a number of typos as well (beyond what is just 
mentioned so far in the thread) that would need fixing.