const(Rvalue) resolved to different overloads

[Timon Gehr via Digitalmars-d]

On 30.12.2016 08:59, Jonathan M Davis via Digitalmars-d wrote:
>> Bug or not? If not, then I don't think there can ever be more than a
>> total of about 0.75 people who fully know D overload resolution. :o)

It's a bug.

https://dlang.org/spec/function.html#function-overloading

The following case is essentially identical:

import std.stdio;

int foo(int x){ return 1; }
int foo(immutable(int) x){ return 2; }

void main(){
     const int x=2;
     writeln(foo(x)); // error
}

The reason why rvalue vs. lvalue can make a difference is implicit 
conversion to immutable for provably unique references:

struct S {
     const(int)[] a;
}

void main(){
     immutable s = const(S)(null); // ok
     const t = const(S)(null);
     immutable u = t; // error
}

(I.e., the lvalue does not match the immutable overload at all.)


> I very much doubt that it's a bug, since it seems like the sort of thing
> that would require extra logic to make happen.

Bugs are wrong logic, often found within unnecessarily convoluted extra 
logic.


Similar case:

class C{}
struct S{
     const(C) c;
}
int foo(S c){ return 1; }
int foo(immutable(S) c){ return 2; }

void main(){
     writeln(foo(const(S)(new C))); // 2
}

Note that the behaviour changes if the type of 'c' is changed to C or 
immutable(C) instead of const(C).

The rule that DMD applies seems to be: if there is at least one const 
indirection and all other indirections are either const or immutable, 
pick the immutable overload. Otherwise, error.

This is not the kind of detail that should matter for overload 
resolution (especially given that fields can be private).