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.

> 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.

D has a lot of decisions geared towards avoiding function hijacking, and
when UFCS was added to the language, it was very purposefully decided that
member functions would win over free functions. It is highly unlikely that
that's going to change. Any such change would require a DIP which explained
in detail the pros and cons of the change and why it either wouldn't break
any existing code or why the code breakage would be worth it and how the
transition would work.

- Jonathan M Davis

Reply via email to