On 11/02/2024 13.28, Jan Schultke via Std-Proposals wrote:
> Yes, I mean that the wording in the core part of the C++ standard
> would not be affected. The existing overload resolution, type
> conversion, etc. rules have to work for extended integers already.
> This is because the implementation could provide those if it wanted
> to, and the core wording must be robust against that.

The phrasing of this paragraph feels a bit ... backwards to me.
Just because you think that "extended integer types" already
have some semantics, it doesn't necessarily mean that's the
right semantics for a new standard-prescribed integer type.

I think we want a new fundamental type for those;
there's no need to have a "primitive" representation
such as "long long" for that, but it should be (for example)
guaranteed different from "long long" .

And we want the right conversion rules even if "long long"
happens to be 128-bits as well on a given platform; see
[conv.rank] and [expr.arith.conv].

Jens