Logical location of template instantiations

Jonathan M Davis via Digitalmars-d digitalmars-d at puremagic.com
Thu Jul 7 08:11:54 PDT 2016


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



More information about the Digitalmars-d mailing list