This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 115d. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.
2024-10-26
Current implementations ignore narrowing conversions during overload resolution, emitting a diagnostic if calling the selected function would involve narrowing. For example:
struct s { long m };
struct ss { short m; };
void f( ss );
void f( s );
void g() {
f({ 1000000 }); // Ambiguous in spite of narrowing for f(ss)
}
However, the current wording of 12.2.4.2.6 [over.ics.list] paragraph 7 says,
Otherwise, if the parameter has an aggregate type which can be initialized from the initializer list according to the rules for aggregate initialization (9.4.2 [dcl.init.aggr]), the implicit conversion sequence is a user-defined conversion sequence with the second standard conversion sequence an identity conversion.
In the example above, ss cannot be initialized from { 1000000 } because of the narrowing conversion, so presumably f(ss) should not be considered. If this is not the intended outcome, paragraph 7 should be restated in terms of having an implicit conversion sequence, as in, e.g., bullet 9.1, instead of a valid initialization.
Rationale (March, 2016):
This is a question of language design and thus more suited to consideration by EWG.
EWG (January, 2021):
Adjust the standard to follow existing implementations. See vote.
Additional notes (March, 2023)
A narrowing conversion is but one of the many circumstances that could make a conversion ill-formed despite the existence of an implicit conversion sequence. Other examples (with implementation divergence) are invoking a private or deleted function, binding a non-const reference to a bit-field, invoking an explicit constructor in list-initialization, invoking a consteval constructor with unsuitable arguments, or initializing an aggregate with incorrectly-ordered designated initializers. A resolution of this issue should thus not be focused on narrow conversions.