[Issue 12583] Allow user defined "retro" range

via Digitalmars-d-bugs digitalmars-d-bugs at puremagic.com
Sat Apr 19 21:11:12 PDT 2014


https://issues.dlang.org/show_bug.cgi?id=12583

--- Comment #6 from Jonathan M Davis <jmdavisProg at gmx.com> ---
> No, it's not a bug. Lookup rules work on overload sets, not on individual
> functions. If you define a ufcs method that overloads with a straight method, > you cannot call the ufcs method, this is intended.

I'm not sure that I agree that that's good behavior, but given how prevalent
UFCS is and how many consider it good practice to use it rather than the normal
function call syntax, it seems like it's a bad idea to name any member
functions with a name which is known to conflict with a free function that is
likely to be used with that type.

And given that unless we use UFCS as a matter of course, there really isn't a
way for types to provide specialized implementations for well-known free
functions (such as retro), I'm very much inclined to argue that we should just
be using UFCS as much as possible and that users should be advised not to name
their member functions with names which are likely to conflict with Phobos
functions which are likely to be used with their types.

Though honestly, I'm inclined to argue that erroring out on foo.retro() because
typeof(foo) defines retro(int) is ultimately a bad idea. It risks making UFCS a
nightmare to use.

And I have a hard time believing that it's going to scale very well to have
templated free functions check to see whether the type that they're being
instantiated with declared a member function which matches. There's nothing
special about retro. It's just one case among many where it would make sense
for a type to provide a specialization for a well-known free function.

Certainly, it seems to me that this situation is exactly what UFCS was designed
for. You call the function without caring whether it's a free function or a
member function, and it just works. If the overloading rules cause problems
with that, then we have a serious problem IMHO, and personally, I think that
this case is the main reason why UFCS makes any objective sense at all - i.e.
making it so that you can call a function without caring about whether it was
defined as a free function or a member function. Every other reason to use UFCS
is subjective.

--


More information about the Digitalmars-d-bugs mailing list