Discussion Thread

This is the discussion thread for the first round of Community Review of DIP 1044, "Enum Type Inference":

https://github.com/dlang/DIPs/blob/e2ca557ab9d3e60305a37da0d5b58299e0a9de0e/DIPs/DIP1044.md

The review period will end at 11:59 PM ET on December 3, or when I make a post declaring it complete. Discussion in this thread may continue beyond that point.

Here in the discussion thread, you are free to discuss anything and everything related to the DIP. Express your support or opposition, debate alternatives, argue the merits, etc.

However, if you have any specific feedback on how to improve the proposal itself, then please post it in the Feedback Thread. The Feedback Thread will be the source for the review summary that I will write at the end of this review round. I will post a link to that thread immediately following this post. Just be sure to read and understand the Reviewer Guidelines before posting there:

https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md

And my blog post on the difference between the Discussion and Feedback threads:

https://dlang.org/blog/2020/01/26/dip-reviews-discussion-vs-feedback/

Please stay on topic here. I will delete posts that are completely off-topic.

On Friday, 18 November 2022 at 15:37:31 UTC, Mike Parker wrote:

The Feedback Thread is here:

https://forum.dlang.org/post/yhlkkahzhabrhtyyqtpd@forum.dlang.org

On Friday, 18 November 2022 at 15:37:31 UTC, Mike Parker wrote:

[...]

I'm skeptical that adding this type of complexity to the language is worth it. Not just that this would add considerably to the learning curve, but because seemingly harmless changes to another part of your program would suddenly introduce ambiguity and cause it to no longer compile.

Consider this example:

import std;

enum JavaStyleGinormousName { a, b, c, d}

void main() {
    auto var = JavaStyleGinormousName.a;
    writeln(var);
    alias B = JavaStyleGinormousName;
    auto var2 = B.a;
    writeln(var2);
}

This makes everything explicit, with no surprises and no additional learning curve for the new user. This proposal essentially boils down to an implicit

alias $. = [something inferred by the compiler depending on the context

On Friday, 18 November 2022 at 18:32:44 UTC, bachmeier wrote:

alias $. = [something inferred by the compiler depending on the context

Ds enum syntax is verbose compared to c; and the code block probaly isnt possible to write

On Friday, 18 November 2022 at 17:54:42 UTC, monkyyy wrote:

The $myEnum syntax is really hideous compared to the .myEnum. The .myEnum syntax feels natural where $myEnum looks like it is some kind macro parameter or something. There is a reason that all other example languages like Swift use the . syntax.

Is it possible to use the . syntax but there is a search hierarchy? If there is a global with the same enum name, you must give the full enum name. There might creep in serious bugs, however often you will have some kind of type mismatch.

The $ syntax is so ugly that I don't want this DIP in its current form.

Continuing discussion from the feedback thread:

On Friday, 18 November 2022 at 17:19:11 UTC, IchorDev wrote:

More or less, yes.

That doesn't necessarily mean you have to list every possible context where ETI could be used one by one. A better approach might be to come up with a set of general, context-independent rules that specify how $identifier is evaluated, and then add special cases only as necessary to cover situations where the rules don't apply.

I'm sure there are many people in the D community who would be happy to help you answer questions like these. Ultimately, though, it is your responsibility as the DIP author to make sure that those questions are addressed before the DIP is submitted to Walter and Atila for formal assessment.

If you feel you lack the experience to do this, you might consider recruiting someone more experienced as a co-author.