Bug 8114 – Methods are delegates, not functions.

class Test { public void foo() { } } static assert(is(typeof(&Test.foo) == void function()));

As horrible as this is, it's intended behavior :) It's the same type you would get if you obtained the funcptr property of a delegate to the same member function. Changing to invalid, if you want to propose a different way to handle it, reopen as an enhancement.

I understand what you mean, but if that's the case, then the intentional behavior itself is a bug. The *correct* way to achieve what was intended would be to add the 'this' parameter inside the parameter list. Otherwise, it results in buggy code, since the data type of the function doesn't match what it's pointing to.

Why is this 'critical'?

I put it as critical since it seemed looked like a bug in DMD (I'd never seen it before and it didn't make sense), but when people said it was intentional I forgot to change the status after re-opening it. I'll make it normal.

http://dlang.org/type.html#delegates "There are no pointers-to-members in D"

(In reply to comment #5) > http://dlang.org/type.html#delegates > "There are no pointers-to-members in D" I think this specifically refers to C++ pointers-to-members which these are not

(In reply to comment #6) > (In reply to comment #5) > > http://dlang.org/type.html#delegates > > "There are no pointers-to-members in D" > > I think this specifically refers to C++ pointers-to-members which these are not What's the difference?

Moreover, I would expect "There are no pointers-to-members in D" to mean "There are no pointers-to-members in D" not "There are pointers-to-members in D, but they aren't of the C++ sort".

I'm just saying, that might be what it means, but is just poorly explained. Taking address of member on the class has been around since D1

(In reply to comment #9) > I'm just saying, that might be what it means, but is just poorly explained. > Taking address of member on the class has been around since D1 Maybe. But it can't possibly be intended that type type of &Test.foo is void function(). It would have to be void function(Test). And the spec would have to explicitly allow it.

(In reply to comment #5) > http://dlang.org/type.html#delegates > "There are no pointers-to-members in D" There aren't though. Pointers to members are data types that relative to a certain class. Functions and delegates aren't relative to any class, they're absolute.

(In reply to comment #11) > (In reply to comment #5) > > http://dlang.org/type.html#delegates > > "There are no pointers-to-members in D" > > There aren't though. Pointers to members are data types that relative to a > certain class. What dictionary are you going by? > Functions and delegates aren't relative to any class, they're absolute. This is only a matter of how C++ happens to notate pointer-to-member types and the dereferencing thereof. (At least a pointer to a member function - a pointer to a member variable is a whole different beast.) Below this level, it's just a function type, the class it's "relative to" just being the type of the implicit this parameter.

(In reply to comment #12) > What dictionary are you going by? C++'s, since that's the only one I've seen that ever mentions the phrase "pointer to member". :P

(In reply to comment #13) > (In reply to comment #12) > > What dictionary are you going by? > > C++'s, since that's the only one I've seen that ever mentions the phrase > "pointer to member". :P There you go. This explains only what the phrase means in a C++ context. In a more general context, there's nothing to say a "pointer to member" must be a distinct type. Suppose this issue is fixed by implementing the points of comment 10. Then &Test.foo is a pointer to a member of Test. It being just a void function(Test), rather than some other, distinct but semantically equivalent type doesn't change this fact.

(In reply to comment #14) > In a more general context, there's nothing to say a "pointer to member" must be a distinct type. It depends on what you mean by "pointer to member". If you say a VARIABLE is a pointer to a member, then yes, it doesn't have to have a distinct type. If you say a TYPE is a pointer to a member, then (by definition), it is a distinct type. (Otherwise, how do you distinguish between a type that is a pointer-to-member vs. one that isn't?)

(In reply to comment #15) > It depends on what you mean by "pointer to member". If it means there are no pointer-to-member _types_ in D, then that's what it should say. > If you say a VARIABLE is a pointer to a member, then yes, it doesn't have to > have a distinct type. > > If you say a TYPE is a pointer to a member, then (by definition), it is a > distinct type. (Otherwise, how do you distinguish between a type that is a > pointer-to-member vs. one that isn't?) You wouldn't. They'd be one and the same type. I don't see any reason for them to be distinguished. If OTOH you implement a pointer-to-member as an index into the vtbl, so that it calls the correct method implementation for the object's subclass, _then_ you need a distinct type for it.

*** This issue has been marked as a duplicate of issue 3720 ***