Should templates have the instantiating scope's protection access rights?
Tofu Ninja via Digitalmars-d
digitalmars-d at puremagic.com
Tue Jul 5 11:48:05 PDT 2016
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.
More information about the Digitalmars-d
mailing list