On Sun, 11 Feb 2024 at 12:29, Jan Schultke via Std-Proposals <std-proposals@lists.isocpp.org> wrote:

> 1) Is that talking about a possible alternative of trying to add such extended as pure library types ...

No, as fundamental types. The core language already permits the
implementation to provide additional extended integers such as
std::int128_t. However, the standard library does not allow an
implementation to define std::to_string(std::int128_t) in that event.
This makes no sense; it's an artificial restriction. The problem is
that the current wording defines these overloads exclusively for int,
long, long long, etc.

Basically, the implementation can provide as many fundamental types it
wants, but it would be illegal to give them library support. That's
dumb.

I don't agree with illegal. The implementation can add overloads of any standard function as long as they don't affect the semantics of valid ISO C++ programs.

So I don't see a problem with adding e.g. to_string(same_as<__int128> auto) because that would not

 

Similarly to std::to_string, the standard defines std::bitset to have
a constructor to have a constructor which takes only unsigned long
long. Even if the implementation provides a 128-bit type, it would not
comply with the standard to add a bitset(std::uint128_t) constructor.

Would adding bitset(same_as<unsigned __int128> auto) prevent any valid ISO C++ programs from compiling?

(Making it a template prevents it from introducing ambiguities for e.g. std::bitset<N>(1) as the existing bitset(unsigned long long) constructor would still be preferred for types that aren't unsigned long long.