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: -------

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: -------

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: -------

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: -------

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: -------

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: -------

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: -------

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: -------