Frist Draft (in this forum): Enum Parameters

Quirin Schroll qs.il.paperinik at gmail.com
Thu May 16 13:59:35 UTC 2024


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).

Well, there’s always going to be legacy code that doesn’t 
interact well with the latest features. It’s unfortunate, but 
true for every new feature that extends APIs.
What are we gonna do? Never ever extend APIs?

> 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.

I cannot help but find this argument quite weak. It only concerns 
library authors. If you write production code and find that a 
function needs to change and forward `ref`, you can just change 
it to do so. Same with `enum`. It’s the same with attributes.

On the other hand, if a library author doesn’t bother to annotate 
functions as `@safe`, the library isn’t usable for SafeD.

> (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.)

The only thing I could imagine doing about this is shortening it 
to `auto enum ref`.


More information about the dip.development mailing list