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

[ryuukk_]

On Monday, 1 May 2023 at 14:03:51 UTC, bachmeier wrote:
> On Monday, 1 May 2023 at 00:34:03 UTC, ryuukk_ wrote:
>
>>> I don't think it's a misconception. It's more like a complete 
>>> lack of clarity.
>
>> the goal is not to use an anonymous enum, the goal is to 
>> leverage the robust type system to avoid repeting yourself, 
>> wich is bad
>>
>> ```
>> Value value;
>> value.type = ValueType.STRING;
>> ```
>>
>> vs
>>
>> ```
>> Value value;
>> value.type = .STRING;
>> ```
>
> This is another case of the "complete lack of clarity" I wrote 
> about in my earlier comment. With an anonymous enum you could 
> write
>
> ```
> value.type = STRING;
> ```
>
> Maybe you have something deeper in mind, but that example does 
> not make a case for changing the language. Rather than 
> shouting, you should put together a better example.
>
> I will let this conversation die. I don't think it's going to 
> resolve anything (and I'm not the one that needs convincing 
> anyway).

Ok.. so you _refuse_ to understand (as opposed to not 
understanding, wich in that case you'd only have to listen and 
learn)

You didn't read my previous comment, so let me copy/paste it:

> the goal is not to use an anonymous enum, the goal is to 
> leverage the robust type system to avoid repeting yourself, 
> wich is bad

And to make sure i'm being understood, the goal is not to make 
code less verbose, quite the opposite, the goal is to encourage 
verbosity while avoiding useless repetitions, the two are not 
compatible

Are you familiar with this popular quote? "democracy dies in 
darkness"? It goes the same way with discussing feature 
suggestions and language impromvents, don't "let this 
conversation die", convince me, argument, don't just try to 
silence me, that won't work