https://issues.dlang.org/show_bug.cgi?id=12583
--- Comment #6 from Jonathan M Davis <jmdavisp...@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. --