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

[Johan]

On Sunday, 20 November 2022 at 16:30:46 UTC, ryuukk_ wrote:
> On Sunday, 20 November 2022 at 16:14:41 UTC, Johan wrote:
>> 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
>
> D has good type system

Irrelevant.

> first off, name properly your functions/types/variables

Irrelevant.

> then about the problem you are raising:

In your long email, you are not addressing at all how this DIP 
addresses any of the problems I am raising. Just mentioning more 
examples of code that are not fixed by this DIP.

>
> `TOK` enum in DMD codebase instead of `SymbolTokenType`

Thank you for this example. Search DMD codebase for `TOK`, and 
tell me how this DIP would matter for renaming `TOK` to 
`SymbolTokenType`:

```
dmd/compiler/src/dmd/cond.d:
   195      {
   196          auto tf = new TypeFunction(ParameterList(), null, 
LINK.default_, 0);
   197:         auto fd = new FuncLiteralDeclaration(loc, loc, tf, 
TOK.reserved, null);
   198          fd.fbody = s;
   199          auto fe = new FuncExp(loc, fd);
   ...
   407              auto exps = new Expressions(length);
   408
   409:             if (rangefe.op == TOK.foreach_)
   410              {
   411                  foreach (i; 0 .. length)
```

```
dmd/compiler/src/dmd/cparse.d:
   112          while (1)
   113          {
   114:             if (token.value == TOK.endOfFile)
   115              {
   116                  addDefines();   // convert #define's to 
Dsymbols
```

This DIP is not needed. `TOK` can happily be renamed to 
`SymbolTokenType`.
Let's not waste time on it.

-Johan