On Sun, Feb 16, 2025, 6:00 PM Jan Schultke <janschultke_at_[hidden]>
wrote:

> > There's something I'm not understanding here. Why is it more of a burden
> for freestanding ? implementations to support a 128-bit integer type than a
> class type that implements 128-bit integer arithmetic? Is it only because
> the type may be slow and users will complain more in the first scenario?
>
> Because you need to implement the functionality of a fundamental type
> in the compiler itself. If you get your compiler on an exotic
> architecture to compile the MSVC STL or libstdc++ or whatever, you get
> this feature without further work.
>

I think "without further work" is not true. If you implement these types in
library, you need to put in the work to come up with a fast implementation.
It probably requires platform intrinsics or assembly language, and a lot of
experimentation if you don't have an existing fast implementation you're
allowed to copy from.

Do we impose a disproportionate burden on freestanding compiler vendors
every time we approve a new core language feature, regardless of what that
feature is? I wasn't under the impression that that was the case, but I
could very well be wrong.


> You also need to decide on an ABI for 128-bit integers, or any N-bit
> integers if this is a fundamental type. If it's simply a class type,
> and you don't care about having a fundamental type at some point, you
> don't really care about this (other than not breaking ABI in the
> future, but even if you did, the consequences of breaking ABI for a
> single class type are lower).
>

If you were going to implement it in library but WG21 decides to make it a
fundamental type, couldn't you just make the ABI whatever the ABI of the
class implementation would have been? Sorry if these are very basic
questions, but I am sure that I am not alone in my ignorance.

>