On 7/30/2024 5:30, Pynix Wnag via Liaison wrote:
> I know, but these all are typedef, Can we build these into language as
> keyword, make it default. and deprecate short long to typedef
> for compatibility

As a practical matter, not really.

In C++, it is possible to overload functions based on types, so you can
have distinct overloads void f(long) and void f(long long), even when
both types map to the same underlying 64-bit type. (The distinction also
matters in C, but there's much fewer places where you can practically
distinguish the types so it doesn't matter as much in reality).

The fundamental issue you run into if you want to rebuild the core
integer type system on top of intN_t types is that C/C++ have 5 types to
cover 4 sizes, and trying to make those 5 types instead into typedefs of
4 real types will cause a lot of existing code to break. Also, as Jens
points out, there are non-8-bit systems in existence, although if there
were real benefits to changing the core language in this way, you might
cobble together a majority on the committee to declare those systems
incompatible with modern C/C++, as was done recently for
one's-complement systems.

It's possible to work around this limitation by making intN_t types
fundamental types in addition to the existing type system, without
trying to make existing types typedefs of those types, but that means
you get even more aliases for the same type, which creates a lot of
extra burden on the language for both the specification to worry about,
implementers to have to implement, and users to figure out how to use.
With already incomplete evidence of how this is being handled with the
recent addition of _FloatN/std::floatN_t types creating subtle
incompatibilities between C and C++, I am confident that this is not a
good idea in the slightest.