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

ryuukk_ ryuukk.dev at gmail.com
Sun Nov 20 16:30:46 UTC 2022


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

first off, name properly your functions/types/variables

then about the problem you are raising:


```D
attack_enemy(1, 10, 5);

void attack_enemy(int id, int damage, float modifier)
{}
```

How do you know the last parameter is a float?

to quote you: "now what the heck is this gratuitous obfuscation"


Now another example:

```D
int currhp = player.hp;
```

is hp a variable? or is it a function that's gonna do some 
logic?, if that's a function, will it throw? will it, is it 
thread safe?

to quote you again:  "now what the heck is this gratuitous 
obfuscation"


The DIP doesn't enforce you to omit the type name, it gives you 
the ability to omit it when the context is clear, let's you setup 
a long and verbose name without sacrificing readability of your 
code when you use it

```D
NetworkState network_state = State.NetworkState.CONNECTED;
```

to quote you again: "now what the heck is this gratuitous 
obfuscation"

the repetition adds useless cognitive load, makes the line harder 
to read, and makes me want to give up proper type scoping 
(putting enum under the struct scope), and it encourages me to 
use shorter enum name, wich gives you poor APIs as a result

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

D is not dynamic typed, we should leverage the type system to 
encourage lean code without sacrificing readable APIs



More information about the Digitalmars-d mailing list