DIP1044---"Enum Type Inference"---Formal Assessment

[ryuukk_]

On Wednesday, 26 April 2023 at 12:50:32 UTC, bachmeier wrote:
> On Wednesday, 26 April 2023 at 11:52:31 UTC, Jacob Shtokolov 
> wrote:
>> On Tuesday, 25 April 2023 at 20:15:39 UTC, ryuukk_ wrote:
>>> void set_connected()
>>> {
>>>     network_connect_state = NetworkConnectState.CONNECTED
>>> }
>>>
>>> MySuperLongNameFlag flag = MySuperLongNameFlag.A | 
>>> MySuperLongNameFlag.B | MySuperLongNameFlag.C | 
>>> MySuperLongNameFlag.D;
>>>
>>>
>>> set_flags(MySuperLongNameFlag.A | MySuperLongNameFlag.B | 
>>> MySuperLongNameFlag.C | MySuperLongNameFlag.D)
>>
>> Okay, I understand this is sometimes really annoying, but in 
>> this example, why can't you just:
>
> Many other solutions were provided as well, including but not 
> limited to
>
> - Using shorter names

Why make your code harder to read ?

```

// just use short name, duh
enum CState
{
    CON, DC, WT
}

void on_con()
{
     st = CState.CON;
}



// no, let me take advantage of the robust type system
enum NetworkConnectionState
{
     CONNECTED, DISCONNECTED, WAITING
}


void on_connecte()
{
     network_state = .CONNECTED;
}
```


> - Using alias

Now you have multiple symbols doing the same thing, that's a 
maintenance downgrade, "refactor? ohhh i forgot to refactor the 
multiple aliases"

> - Using an IDE with autocomplete

Now i need an IDE to code, nice

> - Using copy and paste

Now introduce duplicates that are hard to manage during 
refactors, wich copy pasta is the right one?

Again, all of this was covered and argumented during the DIP 
discussion

The goal is to improve the language, not find excuses or 
workarounds, don't defend obfuscation, move forward