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.


Reply via email to