Date: Wed, 6 Nov 2024 12:07:18 +0100
Il 06/11/24 09:27, Jonathan Wakely via Std-Proposals ha scritto:
>
> My preferred resolution for lwg 4109 would be something like
> conditionally-supported, so either it's well-defined and works or it's
> ill -formed. No UB.
I agree. I don't particularly like either proposed resolution. IMHO:
1) all standard integer types _and_ all available fixed width integer
types should always be supported;
2) support for extended integer types should be implementation-defined;
3) using any other type should be ill-formed, not UB.
A related problem -- whose solution is entirely to be explored -- would
be to enable passing something like BigInt in those facilities. Can we
exactly model the requirements for such types so that users would be
able to plug them in? Such requirements would also be useful elsewhere
(for instance chrono::duration's representation can be a "class
emulating an arithmetic type", whatever that means.)
My 2 c,
--
Giuseppe D'Angelo
>
> My preferred resolution for lwg 4109 would be something like
> conditionally-supported, so either it's well-defined and works or it's
> ill -formed. No UB.
I agree. I don't particularly like either proposed resolution. IMHO:
1) all standard integer types _and_ all available fixed width integer
types should always be supported;
2) support for extended integer types should be implementation-defined;
3) using any other type should be ill-formed, not UB.
A related problem -- whose solution is entirely to be explored -- would
be to enable passing something like BigInt in those facilities. Can we
exactly model the requirements for such types so that users would be
able to plug them in? Such requirements would also be useful elsewhere
(for instance chrono::duration's representation can be a "class
emulating an arithmetic type", whatever that means.)
My 2 c,
--
Giuseppe D'Angelo
Received on 2024-11-06 11:07:21