I submitted DIP1044, "Enum Type Inference", to Walter and Atila on April 1. I received the final decision from them on April 18. They have decided not to accept this proposal.

https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1044.md

The said the proposal was well done and an interesting read, but found it to be too complex for insufficient benefit. They provided the following list of concerns that led them to their decision:

• Given that D already has with, alias, and auto, it does not seem worthwhile to add a special case for enums.
• Semantic analysis in D is strictly bottom-up. This proposal would add top-up type inference on top of that. This presents problems in handling function and template overloads, as well as variadic parameter lists.
• The proposal only allows ETI in some contexts. This is potentially confusing for the programmer, particularly in the presence of mixin templates (which draw symbols from the instantiation context) and function overloads.
• Symbol tables can get very large. Lookups are done via hash table for max speed, but this will not work for ETI. There may be a very large number of "enums in scope", and each one will have to be searched to resolve a member.
• ETI is similar to ADL (Argument Dependent Lookup) in C++. Walter implemented ADL in the Digital Mars C++ compiler and is strongly against allowing anything like it in D. He finds it slow and complex, and few people really know how it's going to work.

Regarding enums in switch statements, Walter suggested we could shorten the with final switch syntax such that the with is implicitly applied to the type of the switch variable:

auto myEnum = MyEnum.a;
with final switch (myEnum) { }

Alternatively, we could make the with implicit for case statements, but that would break existing code.

On Tuesday, 25 April 2023 at 04:54:43 UTC, Mike Parker wrote:

auto myEnum = MyEnum.a;
with final switch (myEnum) { }

Welp, time for me to find a new language then, that's unfortunate..

On Tuesday, 25 April 2023 at 04:54:43 UTC, Mike Parker wrote:

Is it okay to use a new keyword enumswitch that is equivalent to with final switch?

On Tuesday, 25 April 2023 at 06:41:04 UTC, zjh wrote:

If there were an official restriction that could simplify long keywords, that would be great,like:

alias keyword enumswitch=with final switch;

Multiple keywords/@property can also be simplified (pure/@ nogc/@ safe/public/...), but it is best to only allow official simplification, otherwise it will mess up the grammar.

On Tuesday, 25 April 2023 at 04:54:43 UTC, Mike Parker wrote:

That DIP sure became a bikeshed at the last review. Good effort from you and Aya to revise and submit it regardless.

Note though, the links to the community review currently point to ProtoObject DIP review.

This is not good news :-|

On Tuesday, 25 April 2023 at 04:54:43 UTC, Mike Parker wrote:

auto myEnum = MyEnum.a;
with final switch (myEnum) { }

I'm a little glad for reading and reviewing code that this didn't get through, at least without IDE, but I think this would have been quite a useful feature for writing code.

However I think we probably should still implement this in DCD / have better auto-suggest according to the rules here. I think it will be similarly useful having better auto-complete suggestion contexts compared to having new syntax in the language. (maybe being able to trigger it explicitly using $ at the start, but definitely want to have these suggestions being prioritized)

On Tuesday, 25 April 2023 at 04:54:43 UTC, Mike Parker wrote:

IMO this is the correct decision. While a feature like this would be nice to have, it's not of critical importance, so we can afford to have high standards for the quality of the proposal.

During the review process, there was some discussion in the community Discord about generalizing this idea, of literals with "holes" that the compiler can fill in, to other types of data beyond just enums. Perhaps it could even be unified with pattern matching--e.g., you could use a pattern as a literal outside of a switch or match statement, and the compiler would attempt to fill it in based on the context.

I can't say with confidence that such a proposal would be accepted (the concerns about top-down vs bottom-up inference still apply), but I personally would be excited to see one.

On Tuesday, 25 April 2023 at 04:54:43 UTC, Mike Parker wrote:

Firstly I think this is the correct decision, certainly for now, probably forever.

auto myEnum = MyEnum.a;
with final switch (myEnum) { }

What we have at the moment with with is, I think perfectly fine.
The switch(...) with(...) pattern is used rather a lot in the SDC codebase
for example and I think it's very readable.

On the topic of with I do think, and have even implemented ;), with expressions do need to happen eventually. The with statement is a little heavy handed for places where these kinds of shorthands are needed locally.

On Tuesday, 25 April 2023 at 04:54:43 UTC, Mike Parker wrote:

I didn't follow this too closely last year, but I don't see a lot wrong with the "implicit with" approach (or at least I'm not sure how wrong it would be, I would lean toward adding it to a preview switch and see if it broke anything). The DIP proponents would argued against that approach seem to just be saying that the DIP is more powerful than that. Sure, that may be true, but this is also a situation where they probably shouldn't let perfect be the enemy of good. I'd rather "implicit with" than using strings and mixins to hack together the same effect for function argument lists.