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