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

XavierAP n3minis-git at yahoo.es
Sun Nov 27 21:58:00 UTC 2022


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?


More information about the Digitalmars-d mailing list