Enum Type Inference

[ichordev]

[ntrel]

BTW I replied on the parameter thread but it's currently hidden as it got marked resolved: https://github.com/dlang/DIPs/pull/230#discussion_r944212064

[ichordev]

I'd love to write a "grammatical changes" section, but I'm honestly not sure what D grammar is the equivalent of "EnumType.EnumMember"—an enum literal. Perhaps I'd need to add a new grammar label (not sure if this is the right term) for expressions?

[ntrel]

I think just add $ Identifier under PrimaryExpression: https://dlang.org/spec/expression.html#primary_expressions

[ichordev]

[...] how far should inference of the enum type go? One case to consider in general is derived types, meaning can

enum C{ e,f,g,h }
enum D:C{ i=C.f, j=C.g }

...recognise members of each other with ETI?

I don't see why that shouldn't work. I've tweaked the DIP's wording so that it doesn't sound like it's explicitly ruling this out, at least.

For instance, your example is a type delcaration; I didn't give any examples involving type delcarations, but your example follows the principle of all other cases where ETI should be allowed.

If we were to go really ambitious with this, we could say that ETI should apply to any assignment, not just to assignment to enums. For example, we could do int x = $min, or Monotime time = $currTime`. But this would be quite a mission creep so I won't say you should go there.

Don't worry, I would love to author future DIPs for this, but I think that ETI should come first. Think there's very little to disagree over about ETI. It's a simple, lovely little QoL feature that I sorely miss when using D over, say, Swift.

One step at a time is the way to go. If everyone can agree on a little change, then a bigger change in the same vein will have an easier time going through the review stages since it'll have fewer issues on its own. If I wrote a DIP for inference of EVERYTHING… well, I would be so overwhelmed with revising it that I would go insane!