Template Parameter References - The HAC Language
Description: The HAC Language

Next: Template Specialization Issues, Previous: Relaxed Parameters Issues, Up: Template Issues

#### 9.11.2 Template Parameter References

PUNTED. (This is groundwork for template metaprogramming.)

Given a templated definition, such as

         template <pint N> defproc foo(...) { ... }

should the parameter `foo::N` be accessible to the programmer as an rvalue? If not, then should we allow references to internal member values (that may be copies of actual parameters)?

         template <pint N> defproc foo(...) { pint _N = N; }
         pint M = foo<3>::_N;

Should all internal meta-values be publicly accessible as rvalues? Allowing access to such variables is the root of the template metaprogramming paradigm in C++.

Forbidding direct references to the template parameters may inconvenience a programmer by having to explicitly copy-propagate all parameters that she wishes to export. It also avoids any issues that arise with forward declarations and typedefs templates.

Consider the template signature equivalence examples from Template Type Equivalence. Among a set of equivalent forward declarations, which set would be used for lookup? The first? or last? The best answer might be `none': parameters may only be referenced if the complete definition is available.

(Looking forward to the chapter on typedefs...) Now consider the following typedef declaration, continuing from our previous example:

         template <pint N> typedef foo<N+1> goo;
         pint P = goo<3>::N;

`goo` has its own parameter N that `shadows' the base definition's parameter of the same name. (Whatif `goo`'s parameter was renamed to not collide? Then `goo<3>::N` would clearly have to refer to `foo`'s N.) Either way this is disambiguated, the meaning would not necessarily be intuitive. We should simply forbid direct references to template parameters.

Proposal: I am in favor of (what I just said above)