On Sun, 11 Feb 2024, 14:41 Jonathan Wakely, <cxx_at_[hidden]> wrote:

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


Sorry for the incomplete sentence. I meant to say it would not change the
meaning of any existing programs. In this case I'm not sure a container
template is even needed, maybe just to_string(__int128) would be ok. I'd
have to try it out to be confident it wouldn't affect some conversion
operator cases.



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