Bug 3559 – DMD 1.048+ fails to take function pointer from overloaded member functions
Status
RESOLVED
Resolution
FIXED
Severity
regression
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2009-11-30T08:08:00Z
Last change time
2015-06-09T05:11:37Z
Keywords
pull, rejects-valid, wrong-code
Assigned to
yebblies
Creator
code
Comments
Comment #0 by code — 2009-11-30T08:08:06Z
The following code compiles and works fine on DMD 1.047 and older (DMD 1.023 was the earliest one I tested), but no longer compiles with DMD 1.048 up to DMD 1.052 because the compiler cannot »choose« the correct overload when it tries to create the delegate/function pointer. In older versions, the casts were enough of a hint.
Note, however, that the code compiles without any errors if the overload I try to get the address of is the last one declared – in the example below, getting the address of »void foo( float a )« would work fine.
---
template addressOf( alias fn, Type ) {
const addressOf = cast( Type )&fn;
}
class A {
void foo( float a ) {}
void foo( int a ) {}
void bar() {
void* dg = addressOf!( foo, void function( float ) );
auto blah = cast( void delegate( float ) )&foo;
if ( cast( void* )blah.funcptr == dg ) {
// Stdout( "not overridden" ).newline;
} else {
// Stdout( "overridden" ).newline;
}
}
}
class B : A {
override void foo( float a ) {}
override void foo( int a ) {}
}
void main() {
A a = new A();
a.bar;
A b = new B();
b.bar;
}
Comment #1 by clugdbug — 2010-01-12T02:55:45Z
(In reply to comment #0)
> The following code compiles and works fine on DMD 1.047 and older (DMD 1.023
> was the earliest one I tested), but no longer compiles with DMD 1.048 up to DMD
> 1.052 because the compiler cannot »choose« the correct overload when it tries
> to create the delegate/function pointer. In older versions, the casts were
> enough of a hint.
This is because bug 52 was fixed. The compiler used to accept all kinds of garbage.
Comment #2 by code — 2010-01-12T03:33:06Z
(In reply to comment #1)
> This is because bug 52 was fixed. The compiler used to accept all kinds of
> garbage.
If I am not misunderstanding you and the snippet I posted is in fact invalid code (it looks very strange indeed, but this is the only working version I and the folks at #d could come up with), there are now two seperate issues:
Firstly, this bug should in fact be an »accepts-invalid« one, since it compiles if you put the function declarations in a certain order (see the original report).
Secondly, there really ought to be a way to get this check to work for *both* overloaded and non-overloaded functions – or neither of them. With my language designer as well as my developer hat on, the restriction to non-overloaded functions is a rather annoying shortcoming…
Comment #3 by yebblies — 2012-02-11T21:01:49Z
*** Issue 4860 has been marked as a duplicate of this issue. ***