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

2040. Missing type traits related to is_convertible

Section: 99 [meta] Status: Resolved Submitter: Daniel Krügler Opened: 2011-03-03 Last modified: 2020-09-06

Priority: Not Prioritized

View other active issues in [meta].

View all other issues in [meta].

View all issues with Resolved status.

Discussion:

When n3142 was suggested, it concentrated on constructions, assignments, and destructions, but overlooked to complement the single remaining compiler-support trait 

template <class From, class To> struct is_convertible;

with the no-throw and triviality related aspects as it had been done with the other expression-based traits. Specifically, the current specification misses to add the following traits: 

template <class From, class To> struct is_nothrow_convertible;
template <class From, class To> struct is_trivially_convertible;

In particular the lack of is_nothrow_convertible is severely restricting. This was recently recognized when the proposal for decay_copy was prepared by n3255. There does not exist a portable means to define the correct conditional noexcept specification for the decay_copy function template, which is declared as: 

template <class T> 
typename decay<T>::type decay_copy(T&& v) noexcept(???);

The semantics of decay_copy bases on an implicit conversion which again influences the overload set of functions that are viable here. In most circumstances this will have the same effect as comparing against the trait std::is_nothrow_move_constructible, but there is no guarantee for that being the right answer. It is possible to construct examples, where this would lead to the false result, e.g. 

struct S {
  S(const S&) noexcept(false);
 
  template<class T>
  explicit S(T&&) noexcept(true);
};

std::is_nothrow_move_constructible will properly honor the explicit template constructor because of the direct-initialization context which is part of the std::is_constructible definition and will in this case select it, such that std::is_nothrow_move_constructible<S>::value == true, but if we had the traits is_nothrow_convertible, is_nothrow_convertible<S, S>::value would evaluate to false, because it would use the copy-initialization context that is part of the is_convertible definition, excluding any explicit constructors and giving the opposite result.

The decay_copy example is surely not one of the most convincing examples, but is_nothrow_convertible has several use-cases, and can e.g. be used to express whether calling the following implicit conversion function could throw an exception or not: 

template<class T, class U>
T implicit_cast(U&& u) noexcept(is_nothrow_convertible<U, T>::value) 
{
  return std::forward<U>(u);
}

Therefore I suggest to add the missing trait is_nothrow_convertible and for completeness also the missing trait is_trivially_convertible to 99 [meta].

[2011-03-24 Madrid meeting]

Daniel K: This is a new feature so out of scope.

Pablo: Any objections to moving 2040 to Open?

No objections.

[Bloomington, 2011]

Move to NAD Future, this would be an extension to existing functionality.

[LEWG, Kona 2017]

Fallen through the cracks since 2011, but we should discuss it. Alisdair points out that triviality is about replacing operations with memcpy, so be sure this is false for int->float.

[Rapperswil, 2018]

Resolved by the adoption of p0758r1.

Proposed resolution:

  1. Ammend the following declarations to the header <type_traits> synopsis in 21.3.3 [meta.type.synop]:

    namespace std {
  …
  // 20.9.6, type relations:
  template <class T, class U> struct is_same;
  template <class Base, class Derived> struct is_base_of;
  template <class From, class To> struct is_convertible;
  template <class From, class To> struct is_trivially_convertible;
  template <class From, class To> struct is_nothrow_convertible;

  …
}

  2. Modify Table 51 — "Type relationship predicates" as indicated. The removal of the remaining traces of the trait is_explicitly_convertible is an editorial step, it was removed by n3047:

    Table 51 — Type relationship predicates
    Template Condition Comments
    …
    template <class From, class To>
    struct is_convertible;    		 see below From and To shall be complete
    types, arrays of unknown bound, or
    (possibly cv-qualified) void
    types.
    template <class From, class To>
    struct is_explicitly_convertible;    		 is_constructible<To, From>::value a synonym for a two-argument
    version of is_constructible.
    An implementation may define it
    as an alias template.
    template <class From, class To>
    struct is_trivially_convertible;    		 is_convertible<From,
    To>::value     is true and the
    conversion, as defined by
    is_convertible, is known
    to call no operation that is
    not trivial ([basic.types], [special]).    		 From and To shall be complete
    types, arrays of unknown bound,
    or (possibly cv-qualified) void
    types.
    template <class From, class To>
    struct is_nothrow_convertible;    		 is_convertible<From,
    To>::value     is true and the
    conversion, as defined by
    is_convertible, is known
    not to throw any
    exceptions ([expr.unary.noexcept]).    		 From and To shall be complete
    types, arrays of unknown bound,
    or (possibly cv-qualified) void
    types.
    …