any non 8-bit system after 2000, maybe we can drop the bag now.

Joshua Cranmer via Liaison <liaison_at_[hidden]>于2024年7月31日 周三00:00写道：

> 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.
>
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Link to this post: http://lists.isocpp.org/liaison/2024/07/1467.php
>