As discussed here
http://forum.dlang.org/post/[email protected]
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.
Comment #1 by maxim — 2012-09-03T20:27:18Z
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 ***
Comment #2 by issues.dlang — 2012-09-03T20:35:09Z
> 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.
Comment #3 by maxim — 2012-09-03T23:20:34Z
(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.
Comment #4 by issues.dlang — 2012-09-03T23:26:55Z
> 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.
Comment #5 by issues.dlang — 2012-09-04T11:08:44Z
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).
Comment #6 by issues.dlang — 2012-09-04T11:09:40Z
*** Issue 8603 has been marked as a duplicate of this issue. ***
Comment #7 by k.hara.pg — 2012-09-04T19:58:12Z
Bug 8490 (already marked as "resolved invalid") is related.
Comment #8 by robert.schadek — 2024-12-13T18:01:11Z