On Fri, 23 Feb 2024 at 21:55, Jonathan Wakely <cxx_at_[hidden]> wrote:
>
> On Fri, 23 Feb 2024 at 21:44, Jonathan Wakely <cxx_at_[hidden]> wrote:
> >
> > On Fri, 23 Feb 2024 at 21:32, enh via Std-Proposals
> > <std-proposals_at_[hidden]> wrote:
> > >
> > > (https://isocpp.org/std/submit-issue led me to believe there isn't a
> > > public bug database, and i should send a mail here.)
> > >
> > > clang recently started warning about using scoped enums as arguments
> > > to varargs functions without a cast. this caused a lot of warning spam
> > > in Android, and a lot of confusion as to why there's even a warning
> > > here.
> >
> > Is this about varargs functions in general, or printf?
> >
> > I think it's intentional they don't promote when passed via varargs.
> > Why should you get implicit conversions from scoped enumeration types
> > when they don't implicitly convert under any other circumstances?
>
> Also, the wording in [expr.call] very clearly talks about scoped
> enumeration types, so I find it very hard to believe that anybody
> forgot to say what happens for them _when adding the wording about
> what happens for them_:
>
> "Passing a potentially-evaluated argument of a **scoped enumeration
> type** (9.7.1) or of a class type (Clause 11) having an eligible
> non-trivial copy constructor (11.4.4, 11.4.5.3), an eligible
> non-trivial move constructor, or a non-trivial destructor (11.4.7),
> with no corresponding parameter, is conditionally-supported with
> implementation-defined semantics.

The current wording is due to https://cplusplus.github.io/CWG/issues/2347.html

There was a suggestion to do what you want (implicitly promote if the
underlying type would be promoted) but that was not the final
direction that was approved.



>
> So the compiler decides whether to reject it at compile time, or to
> accept and and decides how to pass that argument (maybe it treats it
> the same as the underlying type of the enum) so that it can be
> retrieved as its original type. But if it allows passing it, printf
> still won't know how to extract it again. So it really is undefined,
> in the same way as printf("%f", 1) is: the type being passed does not
> match the printf specifier being used.