DIPX: Enum Literals / Implicit Selector Expression

[Timon Gehr]

On 7/6/22 02:57, Steven Schveighoffer wrote:
> On 7/5/22 7:53 PM, Timon Gehr wrote:
>> So I guess actually there is one open question: At what matching level 
>> should a polysemous enum literal match an enum type? If it's 
>> considered a perfect match, other parameters might cause a resolution 
>> of a name clash, if it's considered a match with implicit conversion, 
>> this does not happen.
> 
> I'm concerned about that though, because this brings what should be an 
> exact match (if you specified the enum fully) into the same category as 
> an implicit conversion.
> 
> For example:
> 
> ```d
> enum E { one }
> 
> foo(E e, uint u); // 1
> foo(E e, int i); // 2
> 
> foo(E.one, 1U); // calls 1
> foo(E.one, 1); // calls 2
> 
> // Now both foo's are at the same level, and there's an ambiguity error
> // because uint <-> int
> foo(#one, 1U);
> ```
> 
> I'd much rather just consider that the type is deferred until the 
> expression is used, and then resolved to the correct type based on the 
> way it's used. The sole focus of this feature should be to just omit 
> enum names when they are *obvious*.
> 
> -Steve

Then you get the same behavior as with lambdas.

```d
enum Foo{ a, b }
enum Bar{ b, c }

void fun(Foo foo, int x){ writeln(foo); }
void fun(Bar bar, float x){ writeln(bar); }

void main(){
     fun(:b, 1);
}
```

So I guess you are saying this should call the first overload?

The reason I am bringing this up is that here, those calls are both legal:

```d
fun(Foo.b, 1); // calls first overload
fun(Bar.b, 1); // calls second overload
```

I don't think this is a huge problem, but it might qualify as a pitfall. 
(It could be argued that removing the enum name from working code should 
either preserve the behavior or error out.) The overloading rules are 
not getting any more complicated though.