Proposed resolution (October, 2019):

Change 7.6.1.3 [expr.call] paragraph 12 as follows:

...Passing a potentially-evaluated argument of a scoped enumeration type or of a class type ( Clause 11 [class]) having an eligible non-trivial copy constructor, an eligible non-trivial move constructor, or a non-trivial destructor (11.4.4 [special]), with no corresponding parameter, is conditionally-supported with implementation-defined semantics. If the argument...

Notes from the September, 2019 teleconference:

The consensus was that passing scoped enumerations to ellipsis should be conditionally-supported behavior, similar to the treatment of class types with nontrivial copy semantics.

Proposed resolution (May, 2019): [SUPERSEDED]

Change 7.6.1.3 [expr.call] paragraph 12 as follows:

...If the argument has an integral or enumeration type that is subject to the integral promotions (7.3.7 [conv.prom]), a scoped enumeration type whose underlying type is subject to the integral promotions, or a floating-point type that is subject to the floating-point promotion (7.3.8 [conv.fpprom]), the value of the argument is converted to the promoted type before the call. These promotions are referred to as the default argument promotions.

Notes from the June, 2018 meeting:

The consensus of CWG was that the value passed ougnt to be widened to match the promoted type of the underlying type.

[Adopted as a DR at the November, 2019 meeting.]

According to 7.6.1.3 [expr.call] paragraph 9,

If the argument has integral or enumeration type that is subject to the integral promotions (7.3.7 [conv.prom]), or a floating-point type that is subject to the floating-point promotion (7.3.8 [conv.fpprom]), the value of the argument is converted to the promoted type before the call. These promotions are referred to as the default argument promotions.

A scoped enumeration with an underlying type that is shorter than int will not be widened when passed to an ellipsis. Should it be?