> 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.

There's certainly a point to be made there, yeah.
I will incorporate that into the draft.

Nonetheless, it seems a lot easier to implement in a library using
intrinsics than to come up with the codegen yourself. There are also
architectural similarities. The general technique for addition is
going to be the same on any architecture that has ADC instructions,
for example. If you just implement __builtin_add_overflow and
libstdc++ uses that in its implementation of operator+, you're
basically done. Adding support for a __builtin_add_overflow intrinsic
is much easier than implementing N-bit operation support.

> 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.

It feels disproportionate to me when the feature could be implemented
in library with absolute certainty, but we choose not to. It would be
a bit like requiring that the implementation supports
multi-dimensional arrays as built-in types instead of std::mdspan and
std::mdarray or whatever.

> 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.

Yes, you could, but then you're de-facto creating an ABI for one of
the fundamental types in your language. This is pretty consequential.
The ABI debates about whether __int128 should have 16-byte or 8-byte
alignment, and what the alignment of _BitInt(128) and above should be
were pretty extensive.

After all, if you're going to make a fundamental type for this, it's
presumably going to be THE _BitInt type that is also found in C, not
just some run-of-the-mill type. std::bit_int should be ABI-compatible
with C's _BitInt, similar to _Atomic and std::atomic. It certainly
feels more consequential to define an ABI for a C type than for a C++
library class.

If you only ever do this as a library class and you're sure you'll
never have _BitInt, or you don't care about breaking ABI in the
standard library, then class std::bit_int's ABI is rather
inconsequential. You just wing it.