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

[Johan]

On Sunday, 20 November 2022 at 01:00:58 UTC, deadalnix wrote:
> On Friday, 18 November 2022 at 15:37:31 UTC, Mike Parker wrote:
>> ## Discussion Thread
>>
>> This is the discussion thread for the first round of Community 
>> Review of DIP 1044, "Enum Type Inference":
>>
>> https://github.com/dlang/DIPs/blob/e2ca557ab9d3e60305a37da0d5b58299e0a9de0e/DIPs/DIP1044.md
>>
>
> I have very simple feedback.
>
> STOP CHANGING THE GOD DAMN SYNTAX!
> STOP, STOP, STOP, and if you still have some doubt, STOP!
>
> Every time, it breaks a ton of tools.
>
> It's not worth it.
>
> If typing the name of the enum is too long, then just use 
> `with` or `alias E = MyEnumNameThatIsTooLongAndAnoyingToType;`.
>
> These changes do not solve any actual problem. They just break 
> tools.

I quite strongly agree.

The DIP does not show any real improvements. The rationale 
mentions "few drawbacks" but then does not mention those actual 
drawbacks, so people can judge whether they are few or not.

The DIP show this example as an improvement:
```
     myObj.myFn($medium, $square, $undefined);
```
Is the height medium?, the location the town square?, the shape 
undefined?
This is the "worse" version:
```
     myObj.myFn(Size.medium, Shape.square, State.undefined);
```

Code will be _read_ much more often than it is _written_.
Please give a real world example where really the enum name is so 
long and tedious that _reading_ it is worse than without (and 
where `with` does not solve the problem).

Besides tooling, also take into account someone relatively 
unfamiliar with D, stumbling upon a `$`. (now what the heck is 
this gratuitous obfuscation?)

-Johan