I am sorry I misread your email. I thought you were speaking about std::string c-tor. 
and seems I copy pasted to_string all over.

On Sun, Feb 11, 2024 at 2:56 PM Jan Schultke <janschultke@googlemail.com> wrote:
> The correct form is std::to_string(std::size_t).

I don't know where you got that information from. The current wording
in https://eel.is/c++draft/string.conversions#lib:to_string defines
overloads:

> to_string(int)
> to_string(long)
> ...

An overload exists for every standard integer type.

> std::to_string(std::int128_t)  - this can not be done

Correct. However, the proposal includes wording changes which would permit it.

> such big number is not "addressable"

Yes it is. A std::int128_t consists of 16 8-bit bytes, so the most
significant byte is found at offset 15. std::size_t is required to
represent the number 15. I think you're mixing up value ranges and
addressability here.

Or perhaps you got confused by std::to_string. std::to_string(123)
produces "123", not a string that has 123 characters.

> some other thoughts - I would love to be able to print 128 bit numbers on the screen using standard ways (std::cout, printf etc) . also to do bit operations faster

Yeah, that would be nice, and that's what the proposal is about :)

> Year ago I tried to do the same with gcc uint128_t and the result was really slow.

I would expect compilers to provide optimal codegen for 128-bit
comparison nowadays. For clang, comparing two 128-bit integers with ==
compiles to:

eq(__int128, __int128):
        xor     rsi, rcx
        xor     rdi, rdx
        or      rdi, rsi
        sete    al
        ret