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.

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.

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.