On Sun, 11 Feb 2024 at 12:29, Jan Schultke via Std-Proposals <
std-proposals_at_[hidden]> 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.



>
>
>