Discussion Thread: DIP 1044--Enum Type Inference--Community Review Round 1

[XavierAP]

On Sunday, 27 November 2022 at 03:28:06 UTC, cc wrote:
>
> Having to copy/paste:
> ```d
> alias A = AttackType;
> alias W = WeaponType;
> alias M = MovementType;
> ```
> is unideal.  And the broader the scope they're declared in the 
> more likely they are to conflict with other shortened alias 
> names.
>
> And then when you have, say `enum EntityState` and `enum 
> EnemySprite`, what then?  `alias ETS`, `alias ESPR`... just 
> further increasing symbolic clutter and cognitive load.

Indeed here we hit the whole rationale of the DIP. Current enum 
syntax in modern languages like D, modern C++, C# etc departs 
from C purposely. I see how it can be tedious when importing C 
enums named in compensation e.g. IMG_INIT.IMG_INIT_jpg. In these 
or other exceptional cases aliasing can help.

But as a general practice shortening names for the sake of 
shortness is very bad practice. This is more genenral than enums, 
and recommended in the literature. Certainly in the company where 
I work, if I use non-self-explanatory or even abbreviated names 
(e.g. A, W, E) my pull request won't be approved until I make 
them readable. I do the same consideration when reviewing other 
people's PRs.

As I said in my first reply, the DIP provides no rationale other 
than current synatx "can be tedious" without providing any use 
case.

It looks to me that the actual rationale of this change is (orher 
than dealing with badly named enums imported from C) to enable 
unreadable coding styles. And to mortgage the language and the 
compiler for it.