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