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

[ryuukk_]

On Sunday, 27 November 2022 at 07:48:48 UTC, XavierAP wrote:
> 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.


> the DIP provides no rationale other than current synatx "can be 
> tedious" without providing any use case.


Wrong, i even personally provided use cases by replying to your 
threads, you seem to ignore them

C++/C# are not "modern" languages, they are old C oriented 
languages, C# repeats the same mistake as C++, they failed to 
improve C enums, they made them worse more verbose and less 
flexible, both doesn't even have pattern matching (C# has that 
just recently)

Thankfully the languages that stray away from C did enums and 
designated initialization of types right! Swift and Zig and to a 
lesser extent Kotlin for example