Bug 7196 – Unfair function address overload resolution
Status
RESOLVED
Resolution
FIXED
Severity
normal
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
All
OS
Linux
Creation time
2012-01-01T17:25:00Z
Last change time
2015-06-09T05:14:53Z
Keywords
patch, rejects-valid
Assigned to
nobody
Creator
timon.gehr
Comments
Comment #0 by timon.gehr — 2012-01-01T17:25:50Z
Tested with DMD 2.057
auto foo(int x){return x;}
auto foo(double x){return x;}
void main() {
auto x = (&foo)(1); // ok
auto y = (&foo)(1.0); // fail
}
Error: cannot implicitly convert expression (1) of type double to int
The code should either compile, or both lines should fail.
This is strange - issue 52 is marked as fixed, so why does it still EVER pick the wrong instance?
Where does the spec address the meaning of &foo if there's more than one function called foo in scope?
Comment #3 by k.hara.pg — 2012-01-02T03:19:13Z
(In reply to comment #2)
> This is strange - issue 52 is marked as fixed, so why does it still EVER pick
> the wrong instance?
This problem is only when the caller of CallExp is AddrExp (== &foo).
bug 51 is the problems on initializer and rhs of AssignExp.
> Where does the spec address the meaning of &foo if there's more than one
> function called foo in scope?
In this case, CallExp can pick the original overload of foo in static.
Therefore compiler should translate from (&foo)(arguments...) to foo(arguments...).
Finally, the overload should be resolved.
Comment #4 by timon.gehr — 2012-01-02T11:47:18Z
(In reply to comment #3)
> (In reply to comment #2)
> > This is strange - issue 52 is marked as fixed, so why does it still EVER pick
> > the wrong instance?
>
> This problem is only when the caller of CallExp is AddrExp (== &foo).
> bug 51 is the problems on initializer and rhs of AssignExp.
>
> > Where does the spec address the meaning of &foo if there's more than one
> > function called foo in scope?
>
> In this case, CallExp can pick the original overload of foo in static.
> Therefore compiler should translate from (&foo)(arguments...) to
> foo(arguments...).
> Finally, the overload should be resolved.
If the compiler rewrites (&foo)(arguments...) to foo(arguments...), is it now able to inline delegates that are called directly like for example {x++;}() ?
Comment #5 by k.hara.pg — 2012-01-02T18:18:56Z
(In reply to comment #4)
> If the compiler rewrites (&foo)(arguments...) to foo(arguments...), is it now
> able to inline delegates that are called directly like for example {x++;}() ?
Sorry, I'm not sure the meaning of 'inline'.
If you means 'optimizing', I don't know direct called delegate would be inlined or not...