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

[ryuukk_]

On Sunday, 27 November 2022 at 21:58:00 UTC, XavierAP wrote:
> On Wednesday, 23 November 2022 at 13:41:12 UTC, ryuukk_ wrote:
>>
>> ```D
>> // verbose API, readable
>> struct SuperLongStruct
>> {
>>     struct SuperLongInnerStruct
>>     {
>>         enum SuperLongEnum
>>         {
>>             VALUE_A, VALUE_B
>>         }
>>
>>         SuperLongEnum super_long_flags;
>>     }
>>     SuperLongInnerStruct some_data;
>> }
>
> Isn't this design artificially conceived to shoe-horn the 
> proposed change as a solution? Such nesting would probably 
> never be advisable, too convoluted and coupled. And in this 
> example (though I understand it's a toy example) there is no 
> reason for nesting: no hiding, and no access of private fields 
> by the nested types.
>
> Certainly the enum here has in this design no reason to be 
> nested other than _namespacing_ it into the other types; and 
> then avoiding expressing this (seemingly absurd but purposeful) 
> namespacing is argued as the reason for a language change. 
> Isn't it more adequate in this example to just un-nest this 
> declaration?

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 don't do OOP or any of that encapsulation crap

If you don't see the code above as an improvement, then you can 
keep use the old behavior, nothing will change for you, as for me 
i will keep advocate for it

And no, i will not subscribe to XavierAP_CODE_STYLE_GUIDELINE.md 
document