Don't enforce the U suffix when it's not necessary

[elBoberido]

I have the feeling that the U suffix is getting out of control and it's not even necessary.
The first exception to MISRA rule 10.3 is this

An essentially signed integer constant expression, with a rank no greater than signed int,
may be assigned to an object of essentially unsigned type if its value can be represented in that type.

https://www.misra.org.uk/LinkClick.aspx?fileticket=-BRmxs8omoM%3d&tabid=57

This means it's perfectly fine to use uint32_t foo = 0; or uint32_t bar = 42;.

Therefore I propose to make use of this exception and don't enforce the U suffix where it's not necessary.

@budrus @MatthiasKillat @dkroenke @marthtz @FerdinandSpitzschnueffler @ithier @mossmaurice @elfenpiff

[MatthiasKillat]

Integer

AFAIK: The rule of the compiler is basically that it uses the smallest type that fits the literal value.
If the literal is then assigned to some variable the regular conversion rules apply and warnings may occur if it is a narrowing conversion or a signed value is assigned to unsigned etc.

The only effect of the U suffix is to tell the compiler that it is to be interpreted as an unsigned number, which it can infer itself if it actually is.

This is well-defined

uint32_t x = 1234U;

1. interpret the string literal as a wide enough type to fit the literal
2. assign the literal to x - narrowing conversion warnings apply

and equivalent to
uint32_t x = 1234;
At the latest since C++ 20 (arguably before for all practical purposes)
int32_t x = 1234U;
is also well-defined: assign 1234 as two`s complement to a signed integer. For "small" positive numbers this makes no difference, for "large" numbers (e.g. 2^32 - 1) it becomes a negative number (in this case -1).

We do not have the latter issue.

Even
uint32_t x = -1;
or
int32_t x = -1U;
are well-defined (again surely for C++20, practically also before https://stackoverflow.com/questions/22623453/c-converting-unsigned-to-signed-integer-portability)

It is always problematic to assign a type with larger bit-with to a smaller one (such as uint64_t to int32_t) and this requires a cast and context knowledge (otherwise there may be a logic error).

In no case that I can imagine or occurs in the code base the addition of U will help us to avoid errors or change the behavior.

Float

For floating point numbers it is a different game and assigning floats literals to double is different than assigning the same double literal (the values are different in general due to the way floats work!)

This means if a floating point literal is desired, the f or F is required!

For this reason I support @elBoberido in this case. If it is not required by some standard we should not make unsigned literals mandatory. I would argue that the standard is bad if it requires something like this and it would need a very good reason to convince me otherwise.

Note that narrowing conversions always need a cast and the corresponding logic needs to ensure they are safe (the compiler can generally not know this).