On Sat, 05 Mar 2011 19:15:17 -0500, kenji hara <k.hara...@gmail.com> wrote:
2011/3/4 Steven Schveighoffer <schvei...@yahoo.com>:
Also, keep in mind that I think UFCS should be restricted to builtins
only
(i.e. primitives + arrays, not AA's, since they map to a struct that
can be
customized in druntime). To provide multiple ways for one to add
members to
classes/structs causes huge ambiguity/hijacking issues.
I think the ambiguity/hijacking will be resolved by overload set.
You do?
The problem is when there is a conflict between an actual member funtion,
and a free function which takes the type as its first argument.
Who wins? The obvious choice is the member function. But let's say the
member function is added to the type long after the external function
exists. People who have written code that uses the external function via
UFCS all of a sudden are now calling the member function, without
warning. This is a form of hijacking.
You could say an ambiguous case should be an error, but then someone is
able to issue a sort of "denial of service" attack by simply defining a
free function which coincides with a member function.
With builtins, there is no conflict. You cannot define member functions
for integers or for arrays, so the ambiguity is gone.
And let's also not forget the WTF factor of when you read code that uses a
UFCS function, where would be the first place you look for it? In the
class or struct.
I see almost no benefit for having UFCS on classes and structs. It is
already possible to add member functions to those types, and the
difference between x(y) and y.x() is extremely trivial. If anything, this
makes member functions lose their specificity -- a member function is no
longer attributed to the struct or class, it can be defined anywhere.
-Steve
