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

[Jonathan M Davis]

On Thursday, February 08, 2018 21:58:39 aliak via Digitalmars-d-learn wrote:
> 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.

D tends to be very picky about what it puts in overload sets in order to
avoid function hijacking - e.g. it doesn't even include base class functions
in an overload set once you've declared one in a derived class unless you
explicitly add an alias to the base class function in the derived class.

Also, D doesn't support "best match" with function overloads. The matches
have to be exact - e.g. as soon as implicit conversions come into play,
there can only be one match. If there's ever a conflict, you get a
compilation error (unlike in C++, which tries to figure out what it thinks
the best match is and go with that, sometimes with surprising results). And
having both the member functions and free functions in the same overload set
would basically require the compiler to go with the "best match," which
simply isn't how D deals with overloads. Sometimes, that's annoying, but it
also prevents a lot of subtle bugs that tend to crop up in C++ code.

https://dlang.org/spec/function.html#function-overloading
https://dlang.org/articles/hijack.html

- Jonathan M Davis