On Thursday, 8 February 2018 at 07:16:43 UTC, Jonathan M Davis
wrote:
It would be a disaster if free functions could override member
functions. For starters, it would be impossible to call the
member function if that were allowed, whereas you can always
call a free function by not using UFCS. And in general, it's
far more desirable to have member function functions override
free functions, because then you can do stuff like have have a
range override find if it can provide a more efficient
implementation than std.algorithm.find.
That could be fixed with a precedence rule though no? Then member
find will be preferred over free find. And it won't be impossible
to call member functions.
Also, in this case where it's an overload, and not an override,
it's very clear what should be called isn't it?
In the case of an override I "feel" it may indeed be a disaster,
but not for the reasons you've stated above though, also not for
any reasons I can think of :) Hijacking maybe? But then again, if
I have a free function and then decide to make a member function
I'm hijacking the free function... hmm.
Cheers
