Uniform call syntax for implicit this.

[Jonathan M Davis]

On Thursday, February 03, 2011 11:15:11 Michel Fortin wrote:
> On 2011-02-03 13:42:30 -0500, Jonathan M Davis <jmdavisProg at gmx.com> said:
> > On Thursday, February 03, 2011 09:54:44 Michel Fortin wrote:
> >> On 2011-02-03 12:43:12 -0500, Daniel Gibson <metalcaedes at gmail.com> said:
> >>> Am 03.02.2011 15:57, schrieb Michel Fortin:
> >>>> On 2011-02-02 23:48:15 -0500, %u <dflgkd at sgjds.com> said:
> >>>>> When implemented, will uniform call syntax work for the "this"
> >>>>> object even if not specified?
> >>>>> 
> >>>>> For example, will foo() get called in the following example?
> >>>>> 
> >>>>> void foo(A a, int b) {}
> >>>>> 
> >>>>> class A {
> >>>>> void test() {
> >>>>> this.foo(10);
> >>>>> foo(10);
> >>>>> }
> >>>>> }
> >>>> 
> >>>> I think it should work.
> >>> 
> >>> I think foo(10) should *not* be equivalent to foo(this, 10).
> >> 
> >> Personally, I'm not sure whether the uniform call syntax will be this
> >> much useful or not, but if it gets implemented I think foo(10) should
> >> be equivalent to foo(this, 10) in the case above. That said, it should
> >> not be ambiguous: if there is a member function foo and a global
> >> function foo and both matches the call, it's ambiguous and it should be
> >> an error.
> >> 
> >> Can this work in practice? We probably won't know until we have an
> >> implementation to play with.
> > 
> > Except that if you have both a member function foo and a free function
> > foo, how can you tell the compiler which to use?
> 
> Indeed, that's a problem. The solution is to sidestep the problem. :-)
> 
> We just have to disallow declaring a module-level function and a
> class-level function with the same name and the same parameter types
> (including 'this' in the parameters).
> 
> 	void foo(A a, int i);
> 
> 	class A {
> 		void foo(int i); // error, same as foo(A, int)
> 	}
> 
> If the module-level function is in a different module, then you can use
> the module name to disambiguate if necessary. If they're in the same
> module, the compiler catches the error during semantic analysis of the
> module.
> 
> I'm not too sure how disruptive this change would be to existing code.
> I'm under the impression that this situation is rare, but I can't say
> for sure.

I take it then that you're suggesting that the compiler automatically select the 
member function when the conflicting free function is a separate module? What 
about if the class or struct was declared in a separate module but the free 
function is in the current module? You're back to the same problem again. The 
only solution I see is for the compiler to just always pick the member function 
if there's an ambiguity, but I don't know if that will cause other problems or 
not. It _could_ change which function is called if the member function 
disappears. Still, I don't see what else you we do, unless we tried to say that 
you couldn't declare a free function with the same name as a member function 
that you use in that module and which conflicted with that member function, but 
that seems awfully restrictive.

And then, of course, when you add alias this and opDispatch into the mix...

There are certain cases where UFCS looks _really_ appealing if not outright 
necesarry, but it could get ugly in some cases. I'm not sure that alias this and 
opDispatch really play nicely together at this point (I rarely use either). 
Adding UFCS on top of that would just make it worse. So, UFCS is _really_ 
appealing, but I don't know if it can be reasonably done.

- Jonathan M Davis