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