free func "front" is not picked up as a candidate when doing range.front(...)

[aliak]

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