This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 112e. See for the official list.


2459. Template parameter initialization

Section: 13.4.3  [temp.arg.nontype]     Status: drafting     Submitter: Davis Herring     Date: 2020-09-21

The initialization of template parameters is severely underspecified. The only descriptions in the existing wording that apply are that the argument is “[converted] to the type of the template-parameter” (13.6 [temp.type] bullet 1.3) and, in 13.4.3 [temp.arg.nontype] paragraph 2,

A template-argument for a non-type template-parameter shall be a converted constant expression (7.7 [expr.const]) of the type of the template-parameter.

This omission is particularly important for template parameters of class type with lvalue template parameter objects whose addresses can be examined during construction. See also issue 2450.

Suggested resolution:

To avoid address-based paradoxes, template arguments for a template parameter of class type C that are not of that type or a derived type are converted to C to produce an exemplar. No restrictions are imposed on the conversion from a template argument to a constructor parameter, since explicit and list-initialization may already be used to limit conversions in a similar fashion. Template arguments that are of such a type are used directly as the exemplar (potentially after a materialization conversion); the effect is as if the template parameter were of type const C& (except that temporaries are allowed). (In the latter case, we must impose some restrictions on glvalue template parameters to interpret them.) Each exemplar is used to copy-initialize the template parameter object to which it is (to be) template-argument-equivalent; the initialization is required to produce a template-argument-equivalent value. The multiple initializations of the template parameter object are (required to be) all equivalent and produce no side effects, so it is unobservable which happen.