www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 8616] New: Make pointers dereference with UFCS like they do with member functions

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

           Summary: Make pointers dereference with UFCS like they do with
                    member functions
           Product: D
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: jmdavisProg gmx.com


--- Comment #0 from Jonathan M Davis <jmdavisProg gmx.com> 2012-09-03 19:41:58
PDT ---
As discussed here

http://forum.dlang.org/post/spjfsyaqrcpboypgfrsd forum.dlang.org

pointers to structs and UFCS don't get along all that well at this point. UFCS
dictates that the first function parameter be the type that the function is
being called on, which means that for UFCS to work with a pointer, the function
must take a pointer.

struct S
{
    auto func(int i) {...}
}

auto foo(S* s, int i) { ... }
auto bar(S s, int i) { ... }

S* s;

s.foo(5); //compiles
s.bar(7); //doesn't compile
(*s).bar(8); //compiles

The problem with this is that while it's consistent with UFCS in general, it's
inconsistent with how member functions get called on pointers to structs.

You can do

S* s;
s.func(12);

as long as func is a member function, but if it's a free function, that only
works if the free function takes an S* rather than an S. So, while calling a
member function on a struct is the same whether you're dealing with a pointer
or not

S* s;
S t;
s.func(12);
t.func(14);

it's different when dealing with a free function and UFCS.

S* s;
S t;
(*s).bar();
t.bar();

What this enhancement request proposes is that functions which take the struct
as their first parameter rather than a pointer to the struct be considered in
UFCS for pointers to that struct as long as there's no ambiguity. So, you could
do

S* s;
S t;
s.bar();
t.bar();

even though bar takes an S, not an S*. Presumably, if there's a conflict

auto fiddly(S* s, float f) {...}
auto fiddly(S s, float f) {...}

S* s;
S t;
s.bar(); //fails to compile due to ambiguity
t.bar(); //presumably compiles, since it would never use the S* version.

then you'll get a compilation error, but as long as there isn't one, allowing
for an S* to be used with UFCS just like S is would be useful and make it so
that UFCS works with pointers to structs like member functions work with
pointers to structs, which is the main reason for UFCS in the first place.

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


Maxim Fomin <maxim maxim-fomin.ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |maxim maxim-fomin.ru
         Resolution|                            |DUPLICATE


--- Comment #1 from Maxim Fomin <maxim maxim-fomin.ru> 2012-09-03 20:27:18 PDT
---
This is duplication of 8603.

The problem is that with this approach pointers are implicitly dereferenced.
Consider function:

void foo (T type) { }

which now can be called:

T var;
T *ptr;
type.foo();
ptr.foo();

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

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



--- Comment #2 from Jonathan M Davis <jmdavisProg gmx.com> 2012-09-03 20:35:09
PDT ---

 The problem is that with this approach pointers are implicitly dereference


Which is what happens when calling member functions on pointers to structs
(unless no member variables are ever used within the function, so no
dereferencing is necessary), so I don't see that as a problem.

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



--- Comment #3 from Maxim Fomin <maxim maxim-fomin.ru> 2012-09-03 23:20:34 PDT
---
(In reply to comment #2)

 The problem is that with this approach pointers are implicitly dereference


 Which is what happens when calling member functions on pointers to structs
 (unless no member variables are ever used within the function, so no
 dereferencing is necessary), so I don't see that as a problem.


Well, if pointers are dereferenced in case of accessing members, then the
problem already exists and can't be reason for not accepting enhancement
proposal.

However, there is still a question what to do when both function are available:
foo(T* ptr, ...);
foo(T val, ...);

I prefer to see the former to have priority over the latter. It may be useful
in cases when the first one was written intentionally for e.x. to check for
null pointer.

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



--- Comment #4 from Jonathan M Davis <jmdavisProg gmx.com> 2012-09-03 23:26:55
PDT ---

 However, there is still a question what to do when both function are available


I'd definitely choose to go with making the code not compile. Otherwise, it
risks function hijacking. You could have

auto foo(S s) {...}

in my.pack which

S* s;
s.foo();

is happily calling, and then when you change the code to import your.pack with

auto foo(S* s) {...}

the code would silently change which function was being called. In general, we
try and make all such situations compilation errors in D.

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


Jonathan M Davis <jmdavisProg gmx.com> changed:

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


--- Comment #5 from Jonathan M Davis <jmdavisProg gmx.com> 2012-09-04 11:08:44
PDT ---
I'm making issue# 8603 a duplicate of this one instead, because IMHO, this one
is much better written (if nothing else, because it frames it as an enhancement
request rather than a bug like 8603 does).

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


Jonathan M Davis <jmdavisProg gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tommitissari hotmail.com


--- Comment #6 from Jonathan M Davis <jmdavisProg gmx.com> 2012-09-04 11:09:40
PDT ---
*** Issue 8603 has been marked as a duplicate of this issue. ***

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



--- Comment #7 from Kenji Hara <k.hara.pg gmail.com> 2012-09-04 19:58:12 PDT ---
Bug 8490 (already marked as "resolved invalid") is related.

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