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

2298. [CD] is_nothrow_constructible is always false because of create<>

Section: 21.3.5.4 [meta.unary.prop] Status: C++14 Submitter: Daniel Krügler Opened: 2013-09-24 Last modified: 2016-01-28

Priority: Not Prioritized

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

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

View all issues with C++14 status.

Discussion:

Addresses US 18

The trait is_constructible<T, Args...> is defined in terms of a helper template, create<>, that is identical to std::declval<> except for the latter's noexcept clause.

If the absence of noexcept is critical to this definition, insert a Note of explanation; otherwise, excise create<> and reformulate in terms of declval<> the definition of is_constructible.

[2013-09-24 Daniel comments and provides resolution suggestion]

Replacing create<> by std::declval<> would make the situation worse, because the definition of is_constructible is based on a well-formed variable definition and there is no way to specify a variable definition without odr-using its initializer arguments. It should also be added, that there is another problem with the specification of all existing is_trivially_* traits, because neither create<> nor std::declval<> are considered as trivial functions, but this should be solved by a different issue.

[2013-09-26 Nico improves wording]

The additional change is just to keep both places were create() is defined consistent.

[2013-09 Chicago]

No objections, so moved to Immediate.

Accept for Working Paper

Proposed resolution:

This wording is relative to N3691.

1. Change 21.3.5.4 [meta.unary.prop] around p6 as indicated:

   -6- Given the following function prototype:

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

   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(create<Args>()...);
   

   […]

2. Change 21.3.5.4 [meta.unary.prop] around p4 as indicated:

   -4- Given the following function prototype:

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

   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 create<From>();
   }
   

   […]