Uniform call syntax for implicit this.

[spir]

On 02/03/2011 10:39 PM, Steven Schveighoffer wrote:
> On Thu, 03 Feb 2011 16:05:01 -0500, spir <denis.spir at gmail.com> wrote:
>
>> On 02/03/2011 08:43 PM, Steven Schveighoffer wrote:
>>> The more I think about it (and read discussions like this), the more I think
>>> that uniform call syntax should only be allowed for types which cannot declare
>>> member functions (arrays, primitives, enums, etc.). Otherwise, we introduce
>>> new ambiguities that serve little purpose except annoyance.
>>
>> More precisely, it should work with all types in position of first parameter,
>> but using implicit this like with member functions. This is ok:
>> void f (C c, I i) {...}
>> auto c = new C();
>> I i;
>> c.f(i);
>> Don't you think so?
>
> But what if C also defines f? I don't think c.f(i) should fail in that case. If
> it doesn't fail, then surprises/hijacking will occur (hey, I thought I was
> calling my f, what gives?!). You could write code like this:
>
> import std.somemodule : A;
>
> void f(A a, int i) {...}
>
> void foo()
> {
> auto a = new A;
> a.f(1);
> }
>
> and then some day, the author of std.somemodule now decides he wants to add a
> member function f(int). All of a sudden, all places you use a.f now mean
> something else (dangerous). This is unacceptable. It's also unacceptable for
> a.f to call your f (confusing/ambiguous, sometimes a.f means your f, sometimes
> it means the member), or to have the compiler error (annoying). I don't see any
> good solution to this, except to say, "nope, you just gotta write f(a, 1),
> tough shit."

Right, I agree.

> I really don't understand the benefit of allowing a.f instead of f(a), it's a
> *trivial* gain at best. Note that if I see your code, I'm going straight to the
> definition of A to try and find the f member function. If I can't find it
> there, with UFC syntax, it could be anywhere.

Ditto.

> OTOH, adding member functions to types that don't allow members, although
> equally as trivial (find(str, "hi") vs. str.find("hi") ), at least is not
> ambiguous :)

That's what I liked in UFCS. But more for conceptual & practical reasons: the 
(pseudo)type name, just like in OO, acts like a namespace englobing all related 
functionality. What I would love for Phobos; ideally, this would come with a 
module system designed in such a way that after:
     import T;
I get access to *all* functionality for elements of type T, using syntax like:
     t.f(...);
(Wherever f is actually implemented; obviously should be in T.d, but this seems 
to be an Utopia in Phobos.)

Denis
-- 
_________________
vita es estrany
spir.wikidot.com