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);
