On Wed, 6 Nov 2024 at 11:08, Giuseppe D'Angelo via Std-Proposals <
std-proposals_at_[hidden]> wrote:

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


Yes, and a BigNum where <random> expects RealType.

The current wording already allows implementations to support those as
extensions. Making it ill-formed to use anything except a standard integer
type larger than char would prevent that.



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

And std::valarray works with "numeric types", whatever they are.
[numeric.requirements] doesn't do a good job of defining it.
There's also "linear algebra value types".