Feedback Thread: DIP 1044--Enum Type Inference--Community Review Round 1
IchorDev
zxinsworld at gmail.com
Mon Nov 21 16:44:30 UTC 2022
On Saturday, 19 November 2022 at 02:35:19 UTC, Walter Bright
wrote:
> Under "Prior Work", the C style of enums should be mentioned.
No. C-style enums are inserted into the same scope as the enum
declaration, not an otherwise explicit declaration with a
contextually inferred type.
> While this is a bit clumsy when there are lot of enum members,
> it suggests a special syntax for making it easy:
>
> enum NewKeywordHere E { ex = 1; }
>
> void tab() {
> E x = ex; // ok
> E y = E.ex; // also ok
> }
>
> I.e. going at this problem the opposite way C++ did.
>
> I submit this is less disruptive to the language than adding $
> and new lookup rules.
This proposal is inadequate as it may cause old code to break,
which is actually disruptive to **users** of the language. It
also makes it harder to distinguish between enums with inferred
types and variables with the same names, and will cause confusing
name conflicts.
> It also puts the choice into the hands of the designer of the
> enum rather than the user of the enum. Isn't it better to make
> this a choice the designer should have?
In practice, designers often make bad decisions. In my experience
D has a highly flexible syntax that allows you to write ergonomic
code in the face of awful library design.
More information about the Digitalmars-d
mailing list