Revision History

Eliminates the suggestions to add is_trivially_convertible, decay_copy, and implicit_cast.
Reasons for this decision are two-fold:

LEWG straw polls indicated no convincing
motivation to add either decay_copy or implicit_cast.

During the Rapperswil 2108 LWG session concerns were expressed that adding is_trivially_convertible
could easily be a cause of nasty compile-time errors or ODR-violations (Similar to those of the pre-existing is_trivially_constructible trait),
when at least one of the template arguments would be a type (such as a pointer type) which is complete according to the core language,
but whose referred to type is incomplete. Another concern was that P0758R0 did not present
a concrete use-case demonstrating the motivation for another intrinsic-depending trait. The author therefore decided to
split-off is_trivially_convertible from this proposal, suggesting to defer a potential addition by an
independent proposal.

The proposal no longer recommends to specify an SG10 feature-testing macro name.

Discussion

Please refer to the previous paper regarding general background and (extended) rationale.

Proposal Candidate

is_nothrow_convertible

The is_nothrow_convertible trait

template <class From, class To>
struct is_nothrow_convertible;

is presumably one of the most often asked for traits related to is_convertible.
One of the earliest official notes of the lack of that feature occurred during the publication of the
N3255 proposal that shortly before the C++11 finalization attempted to standardize a new Standard
Library function template decay_copy as replacement for the existing DECAY_COPY pseudo-function.
Among other reasons (especially the lateness of the feature request), this proposal failed, because it couldn't provide
the correct conditional exception specification, concluding:

"What we would need is std::is_nothrow_convertible."

Shortly after C++11 standardization, LWG 2040 was filed requesting the addition
of is_nothrow_convertible and is_trivially_convertible, but is since then in a kind of zombie state.

There are several concrete use-cases for the is_nothrow_convertible trait:

It could be used to specify the correct noexcept expression for a decay_copy replacement template
for DECAY_COPY, which would resolve one important aspect of LWG 2999.

It could be used to restore the valueable (now conditionally) noexcept specification for several
non-throwing basic_string functions that had been "string_view"-ified, as described by
LWG 2946. As example consider adjusting the currently suggested wording changes for
the following find signature: