Menu
Search

Forums

Forum Index

Jump to page: 1 2 3
Thread overview
Feedback Thread: DIP 1044--Enum Type Inference--Community Review Round 1
Nov 18, 2022
Mike Parker
Nov 18, 2022
Paul Backus
Nov 18, 2022
IchorDev
Nov 18, 2022
Walter Bright
Nov 20, 2022
IchorDev
Nov 21, 2022
Walter Bright
Nov 22, 2022
IchorDev
Nov 22, 2022
Walter Bright
Nov 18, 2022
Walter Bright
Nov 21, 2022
IchorDev
Nov 18, 2022
Walter Bright
Nov 21, 2022
IchorDev
Nov 19, 2022
Walter Bright
Nov 21, 2022
IchorDev
Nov 19, 2022
Walter Bright
Nov 20, 2022
IchorDev
Nov 19, 2022
Walter Bright
Nov 20, 2022
IchorDev
Nov 23, 2022
Quirin Schroll
Nov 24, 2022
IchorDev
Nov 23, 2022
Daniel N
Nov 24, 2022
IchorDev
Nov 24, 2022
IchorDev
Nov 27, 2022
XavierAP
Nov 30, 2022
IchorDev
November 18, 2022
Gravatar of Mike ParkerPosted by Mike ParkerReply
Mike Parker
Gravatar of Mike Parker


Reply

Feedback Thread

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

THIS IS NOT A DISCUSSION THREAD

I will be deleting posts that do not follow the Feedback Thread rules outlined at the following link:

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

The rules are also repeated below. Recently, I have avoided deleting posts that violate the rules if they still offer feedback, but I'm going to tighten things up again. Please
adhere to the feedback thread rules.

The place for freeform discussion is in the Discussion Thread at:

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

You can find DIP 1044 here:

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. At that point, this thread will be considered closed and any subsequent feedback may be ignored at the DIP author's discretion.

Feedback Thread Rules

Posts in this thread that do not adhere to the following rules will be deleted at the DIP author's discretion:

  • All posts must be a direct reply to the DIP manager's initial post, with the following exceptions:
    - Any commenter may reply to their own posts to retract feedback contained in the original post;
    - The DIP author may (and is encouraged to) reply to any feedback solely to acknowledge the feedback with agreement or disagreement (preferably with supporting reasons in the latter case);
    - If the DIP author requests clarification on any specific feedback, the original commenter may reply with the extra information, and the DIP author may in turn reply as above.
  • Feedback must be actionable, i.e., there must be some action the DIP author can choose to take in response to the feedback, such as changing details, adding new information, or even retracting the proposal.
  • Feedback related to the merits of the proposal rather than to the contents of the DIP (e.g., "I'm against this DIP.") is allowed in Community Review (not Final Review), but must be backed by supporting arguments (e.g., "I'm against this DIP because..."). The supporting arguments must be reasonable. Obviously frivolous arguments waste everyone's time.
  • Feedback should be clear and concise, preferably listed as bullet points (those who take the time to do an in-depth review and provide feedback in the form of answers to the questions in the documentation linked above will receive much gratitude). Information irrelevant to the DIP or which is not provided in service of clarifying the feedback is unwelcome.
November 18, 2022
Gravatar of Paul BackusPosted by Paul Backus
in reply to Mike Parker		Reply
Paul Backus
Gravatar of Paul Backus
Posted in reply to Mike Parker


Reply

On Friday, 18 November 2022 at 15:38:59 UTC, Mike Parker wrote:

>

Feedback Thread

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

The second paragraph of the "Description" section reads as follows:

>

In principle, ETI should be allowed anywhere that an enum type is known unambiguously at compile-time. The following is a (non-exhaustive) list of circumstances in which ETI will be permitted.

This kind of vagueness is acceptable in a draft, but cannot be allowed in the final DIP. The description of the proposal must be complete and unambiguous.

Remember: if this DIP is ever implemented, the implementer(s) will be relying on the DIP to determine what to implement, and the reviewers will also be relying on the DIP to determine whether the implementation is correct. Even if you plan to do the implementation yourself, the DIP must give the reviewers enough information that they can check your work.

November 18, 2022
Gravatar of IchorDevPosted by IchorDev
in reply to Paul Backus		Reply
IchorDev
Gravatar of IchorDev
Posted in reply to Paul Backus


Reply

On Friday, 18 November 2022 at 16:38:47 UTC, Paul Backus wrote:

>

This kind of vagueness is acceptable in a draft, but cannot be allowed in the final DIP. The description of the proposal must be complete and unambiguous.

I presume this means that the list of cases must therefore be exhaustive?
I might need help from some experienced implementers to work through that, since there are probably many aspects of D's syntax that I am unfamiliar with. For instance, mixing enum types with ints in an array literal causes it to be int[]. Should ETI work in that case? The easy answer is "no". However, what if D already has a mechanism for figuring out what types have already been used in an array literal? If so, then ETI could work in that example without a special-case, unambiguously. I'd love if any implementers would like to talk about these sorts of cases on the discussion thread. If they are of the opinion that D's pre-existing implementation will not be hindered in the slightest by ETI having very precise implementation requirements, then I don't see why I can't write an exhaustive list of cases myself.

Hopefully that clarifies things.

November 18, 2022
Gravatar of Walter BrightPosted by Walter Bright
in reply to Mike Parker		Reply
Walter Bright
Gravatar of Walter Bright
Posted in reply to Mike Parker


Reply
What happens in combination with function and template overloading is not discussed. For example:

    enum A { a }
    enum B { a }

    void ket(A);
    void ket(B);

    ...
    ket(a);
    ...

That's the simplest case. More complex cases come when there are multiple overloaded functions with diverse enum arguments, resulting in an unbounded combinatorial problem of which combination of enum members will be selected.

This kind of problem comes up whenever we contemplate adding top-down type inference and try to make it work in combination with the current bottom up method. It works in trivial cases as shown in the DIP, but the complex ones are the problem. (Even worse than the function overloading problem is the template overloading problem, as the compiler will need to instantiate the template with each combination of enum inferences just to figure out what the type of the template is.)
November 18, 2022
Gravatar of Walter BrightPosted by Walter Bright
in reply to Mike Parker		Reply
Walter Bright
Gravatar of Walter Bright
Posted in reply to Mike Parker


Reply
The following is not addressed:

    enum E { e };
    int e;
    auto x = e;  // which e?

    void bahb(int);
    void bahb(E);
    bahb(e);  // which bahb?
November 18, 2022
Gravatar of Walter BrightPosted by Walter Bright
in reply to Mike Parker		Reply
Walter Bright
Gravatar of Walter Bright
Posted in reply to Mike Parker


Reply
Scoping rules are not addressed. For example:

    enum E { e };

    void blue()
    {
        int e;
        auto x = e;  // which e?
    }
November 18, 2022
Gravatar of Walter BrightPosted by Walter Bright
in reply to Mike Parker		Reply
Walter Bright
Gravatar of Walter Bright
Posted in reply to Mike Parker


Reply
Under "Prior Work", the C style of enums should be mentioned.

In C, enum members are *not* scoped, they are inserted into the same scope as the enum declaration:

    enum E { ex = 1; };

    void tab() {
        enum E x = ex; // ok
        enum E y = E.ex; // fail
    }

This behavior motivated a lot of C users (including me) to declare C enums thusly:

    enum E { Eex = 1; };

    void tab() {
        enum E x = Eex;
    }

where the enum member name was prefixed with the enum name. This behavior was carried over into C++.

But C++ tired of it, and eventually introduced:

    enum class E { ex = 1; };

    void tab() {
        E x = ex; // fail
        E y = E::ex; // ok
    }

ImportC works by (internally) translating ImportC enums to D thusly:

    enum E { ex = 1; }
    alias ex = E.ex;    // <= re-declaring ex into enclosing scope

    void tab() {
        E x = ex; // ok
    }

All this leads to another way to get the result for D than using `with`:

    enum E { ex = 1; }
    alias ex = E.ex;    // <= re-declaring ex into enclosing scope

    void tab() {
        E x = ex; // ok
        E y = E.ex;  // also ok
    }

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. 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?

It inherently makes this an error:

    enum NewKeywordHere E { ex = 1; }
    int ex = 6; // error, ex is already defined

as it should be.
November 18, 2022
Gravatar of Walter BrightPosted by Walter Bright
in reply to Mike Parker		Reply
Walter Bright
Gravatar of Walter Bright
Posted in reply to Mike Parker


Reply
With the syntax $e to look up an enum member, the compiler will need to search *every* enum that is in scope. Since one of D's strengths is whole program compilation, this can be slow. To speed that up, it will likely require that the compiler maintain a hash table of all the enum fields.

I.e. a parallel symbol table will have to be maintained alongside the regular symbol table.
November 18, 2022
Gravatar of Walter BrightPosted by Walter Bright
in reply to Mike Parker		Reply
Walter Bright
Gravatar of Walter Bright
Posted in reply to Mike Parker


Reply
I'm looking at the DIP:

  auto y = [A.a, $b, $c, $d]; // typeof(y) = A[]
  auto z = [A.c, 64, $b, $b]; // typeof(z) = int[]

Note that the type of an array literal is determined by the common type of all the elements, not just the first element:

  auto a [ 0, 1, 3.0, 4 ]; // double[4]

The DIP says: "ETI is also allowed in array literals for which an explicit enum type can be inferred"

I'm not sure what the rule is. Is it the first element of enum type that sets the rule (left to right), or does:

  auto a = [ $a, A.b, $c ];

work?

What about nested arrays:

   auto a = [[A.b, $b], [$c, $d]];

?
November 20, 2022
Gravatar of IchorDevPosted by IchorDev
in reply to Walter Bright		Reply
IchorDev
Gravatar of IchorDev
Posted in reply to Walter Bright


Reply

On Saturday, 19 November 2022 at 04:33:04 UTC, Walter Bright wrote:

>

The DIP says: "ETI is also allowed in array literals for which an explicit enum type can be inferred"

I'm not sure what the rule is. Is it the first element of enum type that sets the rule (left to right), or does:

auto a = [ $a, A.b, $c ];

work?

Before the structural pass the DIP explicitly stated that it was determined by the first element. I felt that this was enough to conclusively remove any ambiguity, however Micheal was of the opinion that this was not necessary, and removed it because:

>

D already infers the type of literals when it can, so I don't think there's any need to be verbose in describing it. The examples speak well enough.

If what they said is not the case, do you feel that the explicit first-element rule should be re-added?

On Saturday, 19 November 2022 at 04:33:04 UTC, Walter Bright wrote:

>

What about nested arrays:

auto a = [[A.b, $b], [$c, $d]];

?

Since auto b = [[1,2],[0.3,0.4]]; gives a type incompatibility error, I think ETI should be consistent with this behaviour:
The two arrays would be evaluated separately, so the second one would just look like [$c, $d] to the parser and it would return an error.

« First   ‹ Prev
1 2 3
Next ›   Last »