www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 8114] New: Methods are delegates, not functions.

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8114

           Summary: Methods are delegates, not functions.
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: critical
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: wfunction hotmail.com



class Test
{
    public void foo() { }
}

static assert(is(typeof(&Test.foo) == void function()));

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 18 2012
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8114


Steven Schveighoffer <schveiguy yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |schveiguy yahoo.com
         Resolution|                            |INVALID



12:06:24 PDT ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 18 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8114


wfunction hotmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |



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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 18 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8114


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla digitalmars.com



20:25:43 PDT ---
Why is this 'critical'?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 18 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8114




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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 18 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8114


wfunction hotmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|critical                    |normal


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 18 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8114


Stewart Gordon <smjg iname.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |accepts-invalid, spec
                 CC|                            |smjg iname.com



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

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 19 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8114




08:28:48 PDT ---


 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

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 19 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8114








 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?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 19 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8114




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".

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 19 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8114




09:13:32 PDT ---
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

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 19 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8114






 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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 19 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8114






 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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 19 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8114








 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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 19 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8114






 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

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 19 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8114








 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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 19 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8114






 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?)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 19 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8114






 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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 20 2012
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8114


yebblies <yebblies gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
                 CC|                            |yebblies gmail.com
         Resolution|                            |DUPLICATE



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

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