ISO/IEC JTC1 SC22 WG21 P0870R2 2020-04-06
Project: Programming Language C++
Audience: Study Group 6 (Numerics), Library Evolution Working Group Incubator
Giuseppe D'Angelo, giuseppe.dangelo@kdab.comThis paper proposes a new type trait for the C++ Standard Library,
is_narrowing_convertible, to detect whether a type is
implictly convertible to another type by going through a narrowing
conversion.
A narrowing conversion is formally defined by the C++ Standard in [dcl.init.list], with the intent of forbidding them from list-initializations.
It is useful in certain contexts to know whether a conversion between two types
would qualify as a narrowing conversion. For instance, it may be useful to
inhibit (via SFINAE) construction or conversion of "wrapper" types
(like std::variant or std::optional) when
a narrowing conversion is requested.
A use case the author has recently worked on was to prohibit narrowing conversions when establishing a connection in the Qt framework (see [Qt]), with the intent of making the type system more robust. Simplifying, a connection is established between a signal non-static member function of an object and a slot non-static member function of another object. The signal's and the slot's argument lists must have compatible arguments for the connection to be established: the signal must have at least as many arguments as the slot, and the each argument of the signal must be implictly convertible to the corresponding argument of the slot. In case of a mismatch, a compile-time error is generated. Bugs have been observed when connections were successfully established, but a narrowing conversion (and subsequent loss of data/precision) was happening. Detecting such narrowing conversions, and making the connection fail for such cases, would have prevented the bugs.
This proposal is a pure library extension.
It proposes changes to an existing header, <type_traits>,
but it does not require changes to any standard classes or functions and
it does not require changes to any of the standard requirement tables.
This proposal does not require any changes in the core language, and it has been implemented in standard C++.
This proposal does not depend on any other library extensions.
This proposal may help with the implementation of
[P0608R3], the adopted resolution for
[LEWG 227]. In particular, in
[P0608R3]'s wording section, the "invented variable
x" is used to detect a narrowing conversion. However, the same
paragraph is also broader than the current proposal, in the sense that it
special-cases boolean conversions [bool.conv], while the current proposal
does not handle them in any special way. The part about boolean conversions
has been anyhow removed by adoping [P1957R2].
The just mentioned [P1957R2], as a follow up of
[P0608R3], made conversions from pointers to
bool narrowing. It was adopted in the Prague meeting,
therefore extending the definition of narrowing conversion in [dcl.init.list].
We do not see this as a problem: we aim to provide a trait to
detect narrowing conversions exactly as specified by the Standard. Should
the specification change, then the trait detection should also change
accordingly; cf. the design decisions below.
This proposal overlaps with [P1818R1], a proposal
that aims at introducing a distinction between narrowing and widening conversions.
[P1818R1] is much more ambitious than this proposal;
amongst other things, it aims at defining a widening trait.
The wording of [P1818R1] is not complete, but we think
that such a trait might simply yield the negation of the trait proposed here;
it would ultimately depend on the exact definition of what constitutes a
"widening conversion". Anyhow, the adoption of [P1818R1]
is orthogonal to the present proposal.
[P1619R1] and [P1998R1] introduce
functions (called respectively can_convert and
is_value_lossless_convertable) that check whether a given value
of an integer type can be represented by another integer type. This is in line
with the spirit of detecting narrowing conversions, namely, preventing loss of
information and/or preventing undefined behavior. While this proposal works on
types, the functions examine specific values; we therefore think that
the proposals are somehow orthogonal to the current proposal.
Moreover, [P1619R1] and [P1998R1]'s
functions only deal with integer types, while the narrowing definition in
[dcl.init.list] (adopted by this proposal) also deals with floating point and
enumeration types (and, following [P1957R2]'s
adoption, also boolean and pointer types).
The most natural place to add the trait presented by this proposal
is the already existing <type_traits> header, which
collects most (if not all) of the type traits available from the Standard Library.
In the <type_traits> header the is_convertible
type trait checks whether a type is implictly convertible to another type.
Building upon this established name, the proposed name for the trait
described by this proposal shall therefore be is_narrowing_convertible,
with the corresponding is_narrowing_convertible_v type trait helper
variable template.
is_convertible_v<From, To> == true be
a precondition of trying to instantiate
is_narrowing_convertible<From, To>?The author deems this unnecessary. Adding such a precondition would likely make the usage of the proposed trait more difficult and/or error prone.
As far as the author can see, the precondition is not going to dramatically simplify the specification for the proposed trait, or its implementation.
In terms of usage: such precondition would force the usage of
std::conjunction (or similar short-circuit behavior)
rather than a simple logical AND to detect whether there is a non-narrowing
conversion between two datatypes, which is what the proposed type trait will be
used for most of the times. In other words, we claim that the most common use
case will be an expression like
is_convertible_v<From, To> && !is_narrowing_convertible_v<From, To>.
Therefore, we believe that it will be convenient for end users to avoid the
pitfalls related to making is_convertible_v a precondition.
is_narrowing_convertible_v<From, To> yield
true only for the combinations of types listed in [dcl.init.list]?
What about user-defined types?The R1 revision of this paper was limiting the possibility for
the trait to yield true if and only if both From
and To were one of the types listed in [dcl.init.list], which
are all builtin types.
Now, while we strongly want the type trait to match the language definition
of narrowing conversion, there are some objections to simply detecting
if we are in one of the those cases.
For instance, should a conversion from const double
to float be considered narrowing or not? If we take the listing
in [dcl.init.list] literally, then the answer would be "no"
(that is, the trait would have to yield false), because
const double is not in the list.
However, this is not really useful, nor expected. If some code checks whether
there is a conversion between two types and the conversion isn't narrowing,
such code could erroneously infer that this is the case between
const double and float and do the conversion.
(This is in spite of the fact that list-initialization would not work,
because there is a narrowing conversion in the conversion sequence).
To elaborate on this last sentence: the definition of list-initialization
in [dcl.init.list] contains several cases where, if a narrowing
conversion takes place, then the program is ill-formed. We believe
that, more than detecting if a given conversion between two types is
a narrowing conversion (as strictly per the definition),
users want to detect if a conversion has a narrowing conversion,
and thus would be forbidden if used in a list-initialization.
As a consequence, we claim that
is_narrowing_convertible_v<const double, float> should
yield true.
This is not simply doable by stripping From and To
of their cv-qualifiers (e.g. by applying std::decay_t on them),
and then checking if the resulting types form a narrowing conversion. One
must also consider all the other cases for conversions, which necessarily
include user-defined types, as they may define implicit conversion operators
that can be used as part of a conversion sequence that also includes a narrowing
conversion. As an example:
struct S { operator double() const; }
S s;
float f1 = s; // OK
float f2 = { s }; // ERROR: narrowing
We therefore claim that is_narrowing_convertible_v<S, float>
should yield true. A similar example is used in
[P0608R3] and
then [P1957R2]'s design. Slightly adapted:
struct Bad { operator char const*() &&; };
With the adoption of [P1957R2] in the Standard, we
claim that is_narrowing_convertible_v<Bad, bool> should yield
true. For completeness,
is_narrowing_convertible_v<Bad &, bool> should yield
false (there is no conversion), and
is_narrowing_convertible_v<Bad &&, bool> should yield
true.
Note that, although user-defined datatypes are involved, the detection of whether there is a narrowing conversion sticks to the list of narrowing conversions in [dcl.list.init], which deals with fixed number of cases: between certain integer and floating point types; from unscoped enumeration types to a integer or a floating point type; and from pointer types to boolean. We are not proposing to allow any customization to these cases (see below).
is_narrowing_convertible_v<From, To> yield
false for boolean conversions [conv.bool]?The author deems this to be out of scope for the proposed trait, which should have only the semantics defined by the language regarding narrowing conversion. Another trait should be therefore added to detect (implicit) boolean conversions, which, according to the current wording of [dcl.init.list], are not considered narrowing conversions. (Note that with the adoption of [P1957R2], conversions from pointer types to boolean are indeed considered narrowing.)
It is the author's opinion that, in general, implicit boolean conversions are undesiderable for the same reasons that make narrowing conversions unwanted in certain contexts — in the sense that a conversion towards bool may discard important information. However, we recognize the importance of not imbuing a type trait with extra, not yet well-defined semantics, and therefore we are excluding boolean conversions from the present proposal.
is_narrowing_convertible<From, To> use
some other semantics than the narrowing defined in [dcl.init.list]?Given that narrowing is formally defined in the core language, we are strongly against deviating from that definition. If anything, proposals aiming at marking as narrowing certain conversions between user defined types should also amend the core language definition; the type trait would still stick to that definition.
is_narrowing_convertible<From, To> be allowed?We believe that specializations of the trait should be forbidden. This is consistent with the other type traits defined in [meta] (cf. [meta.rqmts]), and with the fact that the current wording of [dcl.init.list] defining narrowing conversions does not extend to user-defined types.
We are aware of broader work happening in the area, such as
[P1818R1]. That proposal introduces a keyword to mark
widening conversions, but one may think of an alternative approach where users
are expected to specialize is_narrowing_convertible in order to
mark a conversion as narrowing. In any case, lifting the above limitation on
specializations would always be possible.
This objection has been raised during the LEWGI meeting in Prague. The objection is sound, in the sense that a future possible change to the definition of narrowing conversion will impact user code using the trait.
On the other hand, during the Prague meeting, EWGI and EWG did not raise this concern regarding this proposal.
First and foremost, we would like to remark that the trait is already
implementable — and has indeed already been implemented — using
standard C++ (e.g. via To{std::declval<From>()}, cf. below).
Any change to the definition of narrowing would therefore already be impacting
user code. The impact would likely go beyond type traits / metaprogramming,
since initialization itself would change semantics.
An example of such a change affecting [dcl.init.list] comes from
[P1957R2], which has been adopted in Prague. That
adoption changed the semantics of code like bool b = {ptr}; (making
it ill-formed; was OK before).
In general, changes to the core language that affected type traits
have already happened. For instance, between C++17 and C++20 the definition
of "aggregate" in [dcl.init.aggr] has been changed, therefore changing the
semantics of the std::is_aggregate type trait.
Similarly, the definitions of "trivial class" and of "trivially copyable class"
in [class.prop] have changed between C++14 and C++17;
meaning that also the type traits std::is_trivial and
std::is_trivially_copy_constructible have changed semantics.
We can therefore reasonably assume that the presence of a trait does not seem to preclude changes to the core language (or, if such an objection was raised when proposing these changes to the core language, it was also disregarded, as the changes did ultimately land).
Finally, it is the author's opinion that code that is using facilities to detect narrowing conversions would like to stick to the core language definition. If the definition changes, we foresee that the detection wants to change too, following the definition. Note that an ad-hoc solution (rather than a standardized trait) may fall out of sync with the core language definition, and thus start misdetecting some cases.
This point was raised during the LEWGI meeting in Prague, and it was deemed unnecessary at this point, because ultimately this proposal is just about a type trait. If it will be deemed useful, adding a concept could always be done at a later time, via another proposal.
is_narrowing_convertible or is_non_narrowing_convertible?The Standard Library does not currently have type traits with a negation in their names,
so the current proposal uses a positive tense, although we foresee that the majority
of the usages are going to be about detecting whether there is no
narrowing conversion between two given types. Note that Standard Library
names such as is_nothrow_constructible are not considered
to be negations; the tense is positive, using nothrow as
an adjective/attribute.
is_narrowing_convertible or is_narrowing?This paper proposes the former, building on top of the existing is_convertible name;
however, we concede that is_narrowing could lead to cleaner code.
Moreover, at the present time, there should be no ambiguity
over the meaning of is_narrowing: the only usage of "narrowing"
in the Standard is about narrowing conversions.
Nonetheless, it may make sense to future-proof the name proposed here, and
therefore go for the slightly more verbose is_narrowing_convertible.
The proposed type trait has already been implemented in various codebases using ad-hoc solutions (depending on the quality of the compiler, etc.), using standard C++ and without the need of any special compiler hooks.
One possible implementation is to exhaustively check whether a conversion
between two types fall in one of the narrowing cases listed in [dcl.list.init].
This particular implementation has been done in
[Qt connect()];
it has obviously maintenance and complexity shortcomings. The most important
part is:
template<typename From, typename To, typename Enable = void>
struct AreArgumentsNarrowedBase : std::false_type
{
};
template<typename From, typename To>
struct AreArgumentsNarrowedBase<From, To, typename std::enable_if<sizeof(From) && sizeof(To)>::type>
: std::integral_constant<bool,
(std::is_floating_point<From>::value && std::is_integral<To>::value) ||
(std::is_floating_point<From>::value && std::is_floating_point<To>::value && sizeof(From) > sizeof(To)) ||
((std::is_integral<From>::value || std::is_enum<From>::value) && std::is_floating_point<To>::value) ||
(std::is_integral<From>::value && std::is_integral<To>::value
&& (sizeof(From) > sizeof(To)
|| (std::is_signed<From>::value ? !std::is_signed<To>::value
: (std::is_signed<To>::value && sizeof(From) == sizeof(To))))) ||
(std::is_enum<From>::value && std::is_integral<To>::value
&& (sizeof(From) > sizeof(To)
|| (IsEnumUnderlyingTypeSigned<From>::value ? !std::is_signed<To>::value
: (std::is_signed<To>::value && sizeof(From) == sizeof(To)))))
>
{
};
(Historical note: at the time this implementation was done, the codebase could only use C++11 features, and some compilers were unable to cope with the SFINAE solution presented below.).
The Qt implementation strictly checks for the one of narrowing cases listed in [dcl.init.list], which is not the aim of the current proposal (cf. design decisions above). Also, the snippet does not yet implement the change introduced by [P1957R2], showing an inherent limitation to such an "exhaustive" solution: it may fall out of sync with the core language.
Another, much simpler implementation is to rely on SFINAE around an expression
such as To{std::declval<From>()}. However, this form is also
error-prone: it may accidentally select aggregate initialization for To,
or a constructor taking a std::initializer_list, and so on.
If for any reason these make the expression ill-formed, then the trait is
going to report that there is a narrowing conversion between the types, even
when there actually isn't one (or vice-versa, depending on how one builds
the trait).
[P0608R3] uses a clever
workaround to avoid falling into these traps: declaring an array, that is,
building an expression like To t[] = { std::declval<From>() };.
This solution is now used in the Standard (in [variant.ctor] and
[variant.assign]), amongst other things, in order to detect and prevent a
narrowing conversion. The trait that we are proposing could be used to replace
the ad-hoc solution, and clarify the intent of it.
Another possible implementation, that uses the just mentioned workaround, is the following one (courtesy of Zhihao Yuan; received via private communication):
template<class From, class To>
inline constexpr bool is_narrowing_convertible_v = false;
template<class T, class U>
concept __construct_without_narrowing = requires (U&& x) {
{ std::type_identity_t<T[]>{std::forward<U>(x)} } -> T[1];
};
template<class From, class To> requires std::is_convertible_v<From, To>
inline constexpr bool is_narrowing_convertible_v<From, To> =
!__construct_without_narrowing<To, From>;
We claim that there is an inherent danger here: it is extremely likely that
non-experts would go for a "naïve", wrong solution
(e.g. To{std::declval<From>()}). This further underlines the
necessity of providing detection of narrowing conversions in the Standard Library,
rather than having users reinventing it with ad-hoc solutions.
In [meta.type.synop], add to the the header synopsis:
template <class From, class To> struct is_convertible; template <class From, class To> struct is_narrowing_convertible;
template <class From, class To> inline constexpr bool is_convertible_v = is_convertible<From, To>::value; template <class From, class To> inline constexpr bool is_narrowing_convertible_v = is_narrowing_convertible<From, To>::value;
In [meta.rel], add a new row to the Type relationship predicates table,
in the same row as for is_convertible:
- Template
template <class From, class To> struct is_convertible;template <class From, class To> struct is_narrowing_convertible;- Condition
see below
- Comments
FromandToshall be complete types, cvvoid, or arrays of unknown bound.
Modify paragraph 5 of [meta.rel]:
5. The predicate condition for a template specialization
is_convertible<From, To>or a template specializationis_narrowing_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; foris_narrowing_convertible<From, To>the conversions shall, moreover, require a narrowing conversion ([dcl.init.list]):To test() { return declval<From>(); }[ Note: This requirement gives well-defined results for reference types, void types, array types, and function types. — end note ] [ Note: For the purpose of establishing whether the conversion is a narrowing conversion, the source is never a constant expression. — end note ]
Thanks to KDAB for supporting this work.
Thanks to Marc Mutz for his feedback and championing this paper in Prague; to Zhihao Yuan for the discussion and some sample code; to André Somers for his feedback.
[Qt] Qt version 5.15, QT_NO_NARROWING_CONVERSIONS_IN_CONNECT, QObject class documentation
[Qt connect()] Qt version 5.15, traits for detecting narrowing conversions
[P0608R3] Zhihao Yuan, A sane variant converting constructor (LEWG 227)
[LEWG 227] Zhihao Yuan, Bug 227 - variant converting constructor allows unintended conversions
[P1957R2] Zhihao Yuan, Converting from T* to bool should be considered narrowing (re: US 212)
[P1818R1] Lawrence Crowl, Narrowing and Widening Conversions
[P1619R1] Lisa Lippincott, Functions for Testing Boundary Conditions on Integer Operations
[P1998R1] Ryan McDougall, Simple Facility for Lossless Integer Conversion