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

[Patrick Schluter]

On Sunday, 20 November 2022 at 16:14:41 UTC, Johan wrote:

>> These changes do not solve any actual problem. They just break 
>> tools.
>
> I quite strongly agree.

Me too.

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

Indeed. This DIP goes also in direct contradiction to the named 
parameter DIP, which strives to make the code more explicit, with 
naming the parameter. This thing would then require for 
readability to call like that:
```
     myObj.myFn(Size: $medium, Shape: $square, State: $undefined);
```

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

Making D as "readable" as Perl. :-)