This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++17 status.

### 2336. `is_trivially_constructible/is_trivially_assignable` traits are always false

Section: 20.15.5.4 [meta.unary.prop] Status: C++17 Submitter: Daniel Krügler Opened: 2013-10-01 Last modified: 2017-07-30

Priority: 3

View other active issues in [meta.unary.prop].

View all other issues in [meta.unary.prop].

View all issues with C++17 status.

Discussion:

In 20.15.5.4 [meta.unary.prop] we have traits to allow testing for triviality of specific operations, such as `is_trivially_constructible` and `is_trivially_assignable` (and their derived forms), which are specified in terms of the following initialization and assignment, respectively:

>     T t(create<Args>()...);

>     declval<T>() = declval<U>()

The wording that describes the way how triviality is deduced, is in both cases of the same form:

> [… ] and the variable definition/assignment, as defined by `is_constructible/is_assignable`, is known to call no operation that is not trivial (3.9, 12).

The problematic part of this wording is that both definitions are specified in terms of an "object construction" function `create` or `declval`, respectively, (The former being a conceptual function, the latter being a library function), but for none of these functions we can assume that they could be considered as trivial — only special member functions can have this property and none of these is one. This problem became obvious, when the similar issue LWG 2298 in regard to `is_nothrow_constructible` was opened.

A possible approach to solve this specification problem is to make a blanket statement for sub-clause 20.15.5.4 [meta.unary.prop] that these helper functions are considered trivial for the purpose of defining these traits.

Using this kind of wording technique can also be used to get rid of the additional helper function template `create`, which is currently needed for the `is_convertible` and the `is_constructible` traits, because both traits are specified in terms of contexts where technically the corresponding "object construction" function would be considered as odr-used. This is problematic, because these traits are defined in terms of well-formed code and odr-using `declval` would make the program ill-formed (see 20.2.6 [declval]). So extending above blanket statement to consider `std::declval<T>()` as not odr-used in the context of the corresponding trait definition would allow for replacing `create` by `declval`.

[2015-05, Lenexa]

STL: would you consider moving the change to 20.10 as editorial or are you uncomfortable with it?
JW: this sounds a viable editorial change
VV: I guarantee you that moving it doesn't change anything
MC: how about this: we move it to Ready as is and if we conclude moving it is editorial we can do it and if not open an issue
STL: I would like to guarantee that the lifting happens
JW: I do that! If it goes in I move it up
MC: move to Ready: in favor: 15, opposed: 0, abstain: 1

Proposed resolution:

This wording is relative to N3936.

1. Add a new paragraph after 20.15.5.4 [meta.unary.prop] p3 as indicated: [Editorial note: The first change in 20.15.5.4 [meta.unary.prop] p3 is recommended, because technically a Clause is always a "main chapter" — such as Clause 20 — but every child of a Clause or sub-clause is a sub-clause]

   > […]

   > -3- For all of the class templates `X` declared in this Clause sub-clause, instantiating that template with a template-argument that is a class template specialization may result in the implicit instantiation of the template argument if and only if the semantics of `X` require that the argument must be a complete type.

   > -?- For the purpose of defining the templates in this sub-clause, a function call expression `declval<T>()` for any type `T` is considered to be a trivial (6.8 [basic.types], 11.4.4 [special]) function call that is not an odr-use (6.3 [basic.def.odr]) of `declval` in the context of the corresponding definition notwithstanding the restrictions of 20.2.6 [declval].

   > […]

2. Modify 20.15.5.4 [meta.unary.prop] p7 as indicated:

   > -7- Given the following function prototype:

   > >     template <class T>
   > >       typename add_rvalue_reference<T>::type create();

   > t The predicate condition for a template specialization `is_constructible<T, Args...>` shall be satisfied if and only if the following variable definition would be well-formed for some invented variable `t`:

   > >     T t(createdeclval<Args>()...);

   > […]

3. Add a new paragraph after 20.15.7 [meta.rel] p2 as indicated: [Editorial note: Technically we don't need the guarantee of "a trivial function call" for the type relationship predicates at the very moment, but it seems more robust and consistent to have the exact same guarantee here as well]

   > […]

   > -2- […]

   > -?- For the purpose of defining the templates in this sub-clause, a function call expression `declval<T>()` for any type `T` is considered to be a trivial (6.8 [basic.types], 11.4.4 [special]) function call that is not an odr-use (6.3 [basic.def.odr]) of `declval` in the context of the corresponding definition notwithstanding the restrictions of 20.2.6 [declval].

   > […]

4. Modify 20.15.7 [meta.rel] p4 as indicated:

   > -4- Given the following function prototype:

   > >     template <class T>
   > >       typename add_rvalue_reference<T>::type create();

   > t The predicate condition for a template specialization `is_convertible<From, To>` shall be satisfied if and only if the return expression in the following code would be well-formed, including any implicit conversions to the return type of the function:

   > >     To test() {
   > >       return createdeclval<From>();
   > >     }

   > […]