On 18.11.22 20:54, Adam D Ruppe wrote:
> 
> BTW I used the word `auto` cuz it is a common thing but it could just as well be anything else, it is just a magic temporary alias after all.

_ is pretty commonly used as a placeholder in other languages.

On 18.11.22 22:09, Walter Bright wrote:
> What happens in combination with function and template overloading is not discussed.

It does not have to be.

> For example:
> 
>     enum A { a }
>     enum B { a }
> 
>     void ket(A);
>     void ket(B);
> 
>     ...
>     ket(a);
>     ...
> ...

Should be 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 is just not true. Overloading introduces zero additional problems. D already has well-defined overloading rules. You only have to be able to match each function on its own.


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

Why "contemplate"? D already has such inference for delegates.

```d
import std.stdio;

enum A{
    a,
    b,
}
enum B{
    b,
    c,
}

void foo(A delegate(A) dg){
    writeln("first overload");
}
void foo(B delegate(B) dg){
    writeln("second overload");
}

void main(){
    foo((x){ // first overload
        static if(__traits(hasMember,typeof(x),"a"))
            return typeof(x).a;
    });
    /+foo((x){ // error, ambiguous
        static if(__traits(hasMember,typeof(x),"b"))
            return typeof(x).b;
    });+/
    foo((x){ // second overload
        static if(__traits(hasMember,typeof(x),"c"))
            return typeof(x).c;
    });
}
```

It works just fine. Now just do literally the same thing for the new enum inference. Probably one can even reuse some of the compiler code.

> (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.) 

Again, this has nothing to do with overloading. In any case, just do the same as for the delegate case and reject if there is no explicitly given enum type to pick up on in the function signature. Instantiating all combinations is never what the user expects.

On 18.11.22 20:33, H. S. Teoh wrote:
> 
> Here's my proposal: use `.` instead of `$`, and if .identifier is
> ambiguous in any way at all, prohibit ITE and require spelling out the
> enum in full. I.e., prohibit it if there's any ambiguity at all with a
> module name, any global identifier, or it can be a member of multiple
> enums currently in scope.

Well, what if you _wanted_ to access the module-scope variable? I guess there are workarounds, but this still seems a bit messy. Probably still better than using $identifier though.

On 11/18/2022 2:49 PM, Timon Gehr wrote:
> Should be ket($a).

Yah, I missed that. That does change how the lookups work from what I posted.

On 19.11.22 02:04, Ki Rill wrote:
> On Friday, 18 November 2022 at 15:37:31 UTC, Mike Parker wrote:
>> ## Discussion Thread
>> [...]
> 
> I think it's not worth adding this to D as well. I have no problem typing out the full name of an enum, and if I or anyone else does face such a difficulty, why not use a short alias?
> 
> ```
> with(a, b, c, d):
> ```
> That's a good idea.

I think this is a little thing that most competing languages have and people are confused that D does not have it.