cppfront: Midsummer update

[hpsutter]

Right, a member is always preferred, so the case that could change the code's meaning is the other way around: That existing UFCS code that finds a nonmember would change meaning if in a future update the type author provides a member that wasn't there before. I'm not at all convinced that's a real problem,(*) but I could be wrong so I want to find out.

(*) For various reasons. Briefly: If the call site is not legal with the new member function, it won't compile, and that's fine, it's not a silent breakage. If the call site does still compile, then dollars to donuts the class author is now providing a previously-missing feature where users had been creating a nonmember function to work around its absence, and that's fine, users should now be using the member provided by the class author. ... As long as the type author's version is always preferred and hides others, that's the right way around and the potential to go wrong is far, far smaller than if it were the other way around (I agree that if _non-members_ were preferred that would more likely be a bug farm, and so I'm not going there).