On 2016-09-05 10:17, Andrei Alexandrescu wrote:
Let me make sure I understand it. The core structure is this:===== module bob; struct S {} void f(S s); module myalgorithm; void test(T)(T t) { f(t); } ===== The core issue here is that f is not considered for lookup. It is a free function in the same module as S. That's not a frequent case and it seems right to not support it in the lookup rules. The simplest solution, which has already been discussed, is to make f a member of S. It is important that does not affect modularity; all protection in D has module-level granularity, so the premise of http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197. So it's for the most part a clerical matter: move the body of f inside S, or if f is already generic define an alias for it inside of S. This is the baseline solution, and it is reasonable. This needs to be properly understood before we look into any others: by a simple mechanical intervention, everything works properly. Every language has such minute needs for minor scaffolding. It must also be understood that changing the lookup rules to make this scaffolding unnecessary bring with them a host of unpleasant consequences. Are we in agreement about the baseline solution?
I thought one of the reasons for UFCS was to be able to make a type support the range interface without modifying the type.
-- /Jacob Carlborg
