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
