Frist Draft (in this forum): Enum Parameters

[Steven Schveighoffer]

On Tuesday, 7 May 2024 at 15:20:24 UTC, Paul Backus wrote:
> On Tuesday, 7 May 2024 at 11:23:10 UTC, Quirin Schroll wrote:
>> You’re right in that `forward` better be mentioned in the DIP. 
>> Writing an answer to this post, I found out that not only 
>> could `forward` easily be adapted to recognize `enum` 
>> parameters and handle them properly by leaving them alone, 
>> `forward` actually would handle them correctly today.
>
> Good to know; thanks for looking into this.
>
> However, the main issue here is not `forward`--it's that in 
> order to write correct generic code with this feature in place, 
> D programmers will forever be obliged to defensively write 
> `auto enum auto ref` on any parameter they intend to forward 
> (and will have to go back and add `auto enum` to many of their 
> existing `auto ref` parameters).

I don't think this is going to be the case. Consider that without 
explicitly forwarding, the difficulty is not in preserving 
refness, but non-refness. If care is not taken (e.g. via using 
forward), then a non-ref parameter suddenly turns into a ref 
parameter (implicitly). This is not the case for enum parameters 
-- enumness is preserved whether it's not an enum or is an enum.

Yes, generic code that wishes to forward enum-ness to another 
thing must use auto enum to accomplish this. However, comparing 
to the the current mechanism, things are pretty inferior. 
Switching from an enum parameter to a runtime parameter involves 
*changing the place where parameters are put*. You currently have 
to remember to create a nested template with an outer template 
that takes a tuple for this to work correctly (something which I 
doubt many generic functions do).

Put another way, if the cost of having the convenience of enum 
parameters is that we must also allow auto enum, I don't think 
this is a large enough drawback.

> Most D programmers already forget to add `auto ref` to such 
> parameters (see for example the vast swathes of Phobos which 
> fail to compile when used with non-copyable types). Adding an 
> additional thing for them to forget is, like I said, setting 
> them up for failure.
>
> (Also, `auto enum auto ref` is quite ugly and "attribute 
> spam"-y, and some programmers will no doubt leave it out of 
> their code intentionally in order to make the code look 
> nicer--as they already do with existing attributes and 
> parameter storage classes.)

Based on what Quirin explained, these attributes are not 
orthogonal. So `auto ref enum` or `auto enum ref` would be 
sufficient. It's at least a little better.

But... even `auto enum ref Typename` is quite noisy, I wish we 
had a combining storage class to do all the inference. `auto ref` 
is kind of ugly on its own, it would be nice to find a better 
way. Note that `auto ref` dates back to a time without 
`@attributes` and also at a time of extreme prejudice against 
adding new keywords.

-Steve