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

[aliak]

On Thursday, 8 February 2018 at 19:32:42 UTC, Jonathan M Davis 
wrote:
> On Thursday, February 08, 2018 08:18:20 aliak via 
> Digitalmars-d-learn wrote:
>> 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.
>
> That's exactly how it works now. If you call a function as if 
> it were a member function, and that type has that member 
> function, then it's that member function that gets called. If 
> that type doesn't have that member function, then free 
> functions are checked.

Wait no, that's not how it works now. Right now if a member 
function with the same name exists, then free functions are not 
even checked. Whereas if there's a precedence rule that prefers 
member functions, then free functions will still be checked if no 
member function with that name can be deduced as a viable 
candidate. How it is now disregards free functions without any 
consideration (if I've understood correctly), whereas I'm asking 
why free functions are not even considered if a member function 
is not an actual candidate. I'm not asking about overriding 
member functions with free functions.

i.e. in my original post, the free function front(int) does not 
exist in type FilterResult.

Cheers,
- Ali