https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69864
--- Comment #9 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #8)
> (In reply to Jonathan Wakely from comment #6)
> > Because int b{2.3} absolutely definitely loses precision, and since it's a
> > constant you can just fix the code.
> >
> > For {u} the compiler doesn't know whether it really narrows or not, since it
> > depends on un time values, so it gives you the benefit of the doubt.
>
> I updated the FAQ, but I actually agree with mgsergio that this behavior is
> inconsistent and not at all how other -Wflags behave. The fact that we have
> to do ugly kludges in the code to support this makes it only more obvious.
>
> I'm actually going to reopen this to propose some improvements that perhaps
> someone would decide to tackle as easy hacks:
>
> * Document that -Wnarrowing also emits errors in doc/invoke.texi
>
> * Make the message for the error and the warning different, for example:
>
> narrowing conversion of constant expression from 'double' to 'int' inside { }
>
> * Do not pretty-print expressions! '2.2999999999999998e+0' is very ugly and
> I'm sure one can easily trick GCC to print absolute non-sense. That is,
> remove %qE and use proper locations/ranges.
>
> * Create a new function in diagnostic.c, e.g.,
>
> extern diagnostic_t pederror (location_t, int, const char *, ...)
> ATTRIBUTE_GCC_DIAG(3,4);
>
> and replace the kludge in cp/typeck2.c with it (possibly fixing PR69872
> along the way). Document when some warnings might be errors (like we have
> precise definitions for permerror/pedwarn).
The kludges are there because gcc used to emit an error even with
-Wno-narrowing.
That broke tons of existing C++ code. There is such a thing as QOI and that
means you have to use a compromise sometimes.
