On Thursday, July 07, 2016 08:39:51 Steven Schveighoffer via Digitalmars-d wrote: > Yes, it is a problem. I still don't understand how the *calling* of a > private function is the problem, vs. the aliasing of it. Why aren't we > preventing the aliasing of the private function in the first place (if > not allowed)? If you can get an alias, you should be able to call it. > > I understand that aliases are strange in this way. What we really need > is an alias to the protection level. An explicit permission given to an > external template that says "for this one instantiation, you can pretend > you have access to this".
What would make sense is if the template instantiation ignored the access level of the aliased symbol and were the same regardless of the access level of that symbol such that the template compiled regardless, but the check for accessibility would be done at the call site. Then the template could compile with a private function just fine, but it wouldn't be callable except where the private function would be callable. I suppose that that could get a bit hairy though when you consider multiple levels, since if you had something like void foo(alias pred, Arg)(Arg arg) { bar(pred)(arg); } void bar(alias pred, Arg)(Arg arg) { pred(arg); } to work even with foo and bar in different modules so long as foo were called in a place where the function being passed to it were callable. So, the buck would have to be passed at every point that the symbol were passed as an alias argument such that the check for accessibility was only done when the symbol first became an alias. Regardless, while that idea makes theoretical sense, I'm not sure that it makes sense from the standpoint of how alias parameters are currently implemented. I'm inclined to think though that something along those lines would be the best solution (at least from a usability perspective, not necessarily from the compiler's perspective). - Jonathan M Davis