On Tuesday, 5 July 2016 at 18:04:31 UTC, Steven Schveighoffer
wrote:
The clear problem with this solution is that this means you
must use the instantiating module as part of the template
definition. A template instantiation with exactly the same
parameters must behave exactly the same, no matter where it was
instantiated from.
What this means, is that each instantiation is now tied to the
module instantiating it, with no code reuse. I think at the
very least, this should be opt-in if it even makes sense to do.
Ah that is a really good point, I knew it would muck something
up. But I suppose in a lot of cases this doesn't really matter,
if the template is accessing private things then it already
couldn't be reused outside of the module. I think it would make a
difference in cases where the template does some kind of
reflection or conditional compilation based on if it has access
or not. Still opt-in I think.
Also there could be code re-use wherever the access rights match.
So if an argument is marked as opt-in, only the instantiation
scope's access to that argument would need to be tied to the
template instantiation. I suppose that means there would be 4
possible instantiations, one for private, package, protected, and
public access.
