[Issue 5328] The addressof-expression that should be rejected is accepted

d-bugmail at puremagic.com d-bugmail at puremagic.com
Mon Dec 6 09:23:05 PST 2010


http://d.puremagic.com/issues/show_bug.cgi?id=5328


nfxjfg at gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nfxjfg at gmail.com
            Version|D2                          |D1 & D2
         OS/Version|Windows                     |All


--- Comment #1 from nfxjfg at gmail.com 2010-12-06 09:21:27 PST ---
It's a feature, not a bug. You can take the address of methods without
providing an object reference (i.e. no this pointer, or what would be the
context member of method delegates).

The returned function pointer is simply what the class' vtable contains. The
function signature is the same as the signature of a proper delegate to the
method. It doesn't make sense to call the function pointer by itself (wrong
calling convention, this pointer is missing), but it's useful for other things.

E.g. you can use the type of the function pointer value in meta programming to
get the method's signature. That's very important for meta programming. You
could just instantiate a new object, and then analyze the delegate, but why
should you need to construct a dummy object? For the actual value of the
function pointer there are also valid uses. Think about serialization of
delegates, for example.

Note that the delegate property .funcptr return a similarly non-sensical
function pointer. The context is missing and the calling convention is
incompatible. If you call it, you get an access violation as well.

What is happening here is that the language "designers" just didn't feel like
introducing a dedicated separate function type for this purpose. Instead, they
reused the "normal" function pointer type, even if calling it makes no sense.
Basically it's a quick language hack that endangers type-safety and confuses
users.

Btw. the code inside A.this is not accepted, because the "A." from "&A.m" just
qualifies the member "m". Inside the ctor it's exactly the same as writing
"&m". And &m is a delegate, not a function. So everything is alright. Though
this slight syntactic ambiguity is another hint that D as a language is
actually quite unorthogonal and full of special cases. Maybe "&typeof(this).m"
in the ctor would do the same as the &A.m in main()?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------


More information about the Digitalmars-d-bugs mailing list