Should templates have the instantiating scope's protection access rights?

[ZombineDev via Digitalmars-d]

On Wednesday, 6 July 2016 at 08:45:25 UTC, Tofu Ninja wrote:
> On Wednesday, 6 July 2016 at 08:05:38 UTC, Lodovico Giaretta 
> wrote:
>> Thinking about this, maybe the choice about attributes should 
>> be made by the user, so that if I want to give emplace access 
>> to private ctors of my structs, I have to explicitly declare 
>> inside my module that I'm going to give emplace those rights 
>> (which in turn are propagated to whatever templates emplace 
>> uses internally).
>> This way the template writer doesn't have to bother whether 
>> his template needs those rights, it is clear which templates 
>> have them without looking at their declarations, and users can 
>> decide not to grant these rights (bonus point: this way 
>> nothing changes behaviour unless the user wants so).
>
> That is an option too. However there would still need to be 
> some way for the rights to get carried through multiple levels 
> of templates. I suppose retransmission could be done in two 
> ways, explicitly or implicitly. I am not sure which way would 
> be better.
>
> If it was explicit, things like allocator.make would need to 
> explicitly retransmit the access rights down to emplace. 
> Something like :
>
> ######################################
> auto make(T, A, ARGS...)(A alloc, ARGS args) {
>    // ...
>    emplace!(@ShareAccess T)(/* ... */);
>    //...
> }
>
> // Some other module
> class myClass{
>     private this(int x){}
> }
> // ...
> auto x = Mallocator.make!(@ShareAccess myClass)(5);
> // Access rights get transmitted into make and then make 
> retransmits them into emplace
> ######################################
>
> If it was implicit the @ShareAccess in make would not be 
> necessary, the access rights would carry through to emplace 
> implicitly. I am not sure it would be a good option though 
> because access might get accidentally granted somewhere it 
> shouldn't.
>
> Having it be opt-in by the user also resolves the range 
> function example I had earlier where it needed access to 
> mypred. In this case I think the implicit retransmission is 
> probably better, as it would allow any range function to not 
> care about retransmitting the rights if they pass the argument 
> to other templates.

If mixin could work with normal templates, as well as mixin 
templates, the following would work:

auto make(T, A, ARGS...)(A alloc, ARGS args) {
    // ...
    mixin emplace!T(/* ... */);
    //...
}

// Some other module
class myClass{
     private this(int x){}
}
// ...
auto x = mixin Mallocator.make!myClass(5);