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

[XavierAP]

On Sunday, 27 November 2022 at 23:13:39 UTC, ryuukk_ wrote:
>
> Ok so you disagree just to disagree, that's unfortunate
>
> Here if you want a snippet of a code from my project: 
> https://forum.dlang.org/post/bapjpjlbljjhhwcworvz@forum.dlang.org
>
> ```D
> ctx.network_state = State.NetworkState.CONNECTED;
>
> // vs
>
> ctx.network_state = .CONNECTED;

I didn't mean to be dismissive. And for the record I'd be OK with 
adding to D most kinds of inference as long as it didn't require 
new syntax (such as `$` or adding to `.`) and were 100% sure and 
safe. This might be possible for enums at least in 
initializations or even assignments (?) but it's not the current 
DIP (and there are probably other difficulties even with this).

All I'm saying is, nesting your types has no other effect (since 
there's no private data in between) than namespacing them, and so 
requiring yourself to qualify this namespacing. This is your 
choice; purely stylistic as far as I can tell. Then you want to 
be able to write code without this namespacing, and for this you 
suggest a lexical change. But this particular use case could be 
solved with a different stylistic design choice when declaring 
your types; so I don't see the need for the language change.

This is my main point: the DIP discussion should start on the 
concrete problem(s) and use cases that it's supposed to solve:
* enums imported from C
* nested enums
* long/bad names
* ...?

The discussion should not be so subjective or revolve around what 
styles it enables or what ones different people prefer.