Should templates have the instantiating scope's protection access rights?
Tofu Ninja via Digitalmars-d
digitalmars-d at puremagic.com
Tue Jul 5 10:46:54 PDT 2016
Sorry if this has been posted before.
One thing that constantly bugs me about D is how the protection
system works when using templates. Currently the a template
instantiation has the protection rights from the declaration
scope, but this is not really congruent with how a lot of
templates are used.
For example in phobos it is common to see something like:
module bar;
void foo(alias pred, R)(R range) { /* somehow uses pred on
the range elements */ }
Its pretty common throughout std.algorithm. However, because of
the way the protection system works, the pred that is passed in
MUST be public. For example the following code won't work:
private void mypred(RangeElementType x){ /* do something
with x */ }
...
import bar : foo;
foo!mypred(someRange);
Because foo is declared in another module, mypred MUST be public.
I am passing mypred explicitly, there is no way I didn't intend
for foo to have access to it. This causes lots of unnecessary
public functions.
An even more annoying consequence of this is that emplace can
never be used with private constructors, this fundamentally puts
it in a weaker position than new. This is actually a serious
problem for std.experimental.allocator. You can't use an
allocator in the same way you use new.
One possible solution could be that templates have the access
rights of the instantiating scope. This is honestly what I expect
most of the time but there are probably cases where this would
muck things up. Maybe a more case by case solution would be
better.
Thoughts?
More information about the Digitalmars-d
mailing list