D issues are now tracked on GitHub. This Bugzilla instance remains as a read-only archive.
Issue 7196 - Unfair function address overload resolution
Summary: Unfair function address overload resolution
Status: RESOLVED FIXED
Alias: None
Product: D
Classification: Unclassified
Component: dmd (show other issues)
Version: D2
Hardware: All Linux
: P2 normal
Assignee: No Owner
URL:
Keywords: patch, rejects-valid
Depends on:
Blocks:
 
Reported: 2012-01-01 17:25 UTC by timon.gehr
Modified: 2015-06-09 05:14 UTC (History)
2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description timon.gehr 2012-01-01 17:25:50 UTC 
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.
Comment 1 Kenji Hara 2012-01-02 01:25:23 UTC 
https://github.com/D-Programming-Language/dmd/pull/600

AddrExp that is yet not bounded into an variable should keep unresolved overload information.
So the both lines should compile.
Comment 2 Stewart Gordon 2012-01-02 02:43:35 UTC 
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 Kenji Hara 2012-01-02 03:19:13 UTC 
(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 timon.gehr 2012-01-02 11:47:18 UTC 
(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 Kenji Hara 2012-01-02 18:18:56 UTC 
(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...