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?

On Sun, Feb 16, 2025, 5:42 PM Jan Schultke via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Thank you for your thoughts, Arthur.
>
> I have posted a draft at https://isocpp.org/files/papers/D3639R0.html
> which discusses some of your points now.
>
> Considering that _BitInt is only guaranteed to give you 64 bits, I am
> sceptical of the "C does it anyway" claim. If MSVC already supported
> bit-precise integers with a very large width, I could get behind that,
> but it doesn't. I've also received numerous concerns from people
> regarding my 128-bit paper, and was suggested multiple times to make
> it freestanding-optional.
>
> If we want portability, then crutching on C's _BitInt is just not
> going to do the job, at least not in the current environment. A
> library type could easily have guaranteed freestanding support for a
> million bits, considering that it's just an array with some operator
> overloads, nothing that would require the compiler vendor to do much
> work. That is, unless the vendor wants to do the work and back "class
> bit_int" by a fundamental type.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>