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