Date: Thu, 26 Feb 2026 22:42:02 +0100
On Thu, 26 Feb 2026 at 22:28, Jens Maurer <jens.maurer_at_[hidden]> wrote:
>
>
> On 2/26/26 17:44, Jan Schultke via Std-Proposals wrote:
> > Hi,
> >
> > I'm working on another proposal that may likely be a "slam dunk":
> > https://isocpp.org/files/papers/D4037R0.html <
> https://isocpp.org/files/papers/D4037R0.html>
> >
> > In short, this allows std::uniform_int_distribution<unsigned char> and
> such things, which is currently IFNDR/compile-time UB.
> https://cplusplus.github.io/LWG/issue2326 <
> https://cplusplus.github.io/LWG/issue2326> previously attempted the same,
> but was closed as NAD because it was considered a feature request.
> >
> > I'm mainly posting here to see if anyone has some historical context
> into why this was ever disallowed, or in case someone has a good reason not
> to allow it now; I don't see any good reason.
>
> For generators, using "unsigned char" and friends seems to make zero sense,
> in particular with the generators supplied in the standard. Making this
> diagnosable seems to be a plus.
>
>
> I can see why someone wants to have a
>
> std::uniform_int_distribution<unsigned char>(0, 255)
>
> which is the same as
>
> std::uniform_int_distribution<unsigned int>(0, 255)
>
> except for the difference in return type; the value range is the same.
>
> The wording in the paper isn't sufficiently differentiating those two
> cases.
>
You mean wording as in the proposed wording changes, or the discussion in
the paper? I think the proposed wording changes are clear.
In any case, as I've said to Sebastian, I think there is no motivation for
disallowing the instantiation of engines using single-byte types. One could
equally argue that certain instantiations with short should be disallowed
because they are of low quality, but that seems like rather pointless
policing to me. One could also make a similar domain-specific argument that
instantiating std::string_view with 64-bit or 128-bit integers should be
disallowed (even if char_traits is provided) because 64 bits or 128 bits is
excessive and weird for a character type. It's not really our job to
declare what template arguments are "too bad practice" to be provided. If
you want to instantiate std::array<std::nullptr_t, 1024>, as dumb as it is,
go for it.
As things stand, GCC and Clang permit the use of 8-bit types in generators,
and I don't see a compelling reason to disallow it. The implementation
works and the wording can easily work.
>
>
> On 2/26/26 17:44, Jan Schultke via Std-Proposals wrote:
> > Hi,
> >
> > I'm working on another proposal that may likely be a "slam dunk":
> > https://isocpp.org/files/papers/D4037R0.html <
> https://isocpp.org/files/papers/D4037R0.html>
> >
> > In short, this allows std::uniform_int_distribution<unsigned char> and
> such things, which is currently IFNDR/compile-time UB.
> https://cplusplus.github.io/LWG/issue2326 <
> https://cplusplus.github.io/LWG/issue2326> previously attempted the same,
> but was closed as NAD because it was considered a feature request.
> >
> > I'm mainly posting here to see if anyone has some historical context
> into why this was ever disallowed, or in case someone has a good reason not
> to allow it now; I don't see any good reason.
>
> For generators, using "unsigned char" and friends seems to make zero sense,
> in particular with the generators supplied in the standard. Making this
> diagnosable seems to be a plus.
>
>
> I can see why someone wants to have a
>
> std::uniform_int_distribution<unsigned char>(0, 255)
>
> which is the same as
>
> std::uniform_int_distribution<unsigned int>(0, 255)
>
> except for the difference in return type; the value range is the same.
>
> The wording in the paper isn't sufficiently differentiating those two
> cases.
>
You mean wording as in the proposed wording changes, or the discussion in
the paper? I think the proposed wording changes are clear.
In any case, as I've said to Sebastian, I think there is no motivation for
disallowing the instantiation of engines using single-byte types. One could
equally argue that certain instantiations with short should be disallowed
because they are of low quality, but that seems like rather pointless
policing to me. One could also make a similar domain-specific argument that
instantiating std::string_view with 64-bit or 128-bit integers should be
disallowed (even if char_traits is provided) because 64 bits or 128 bits is
excessive and weird for a character type. It's not really our job to
declare what template arguments are "too bad practice" to be provided. If
you want to instantiate std::array<std::nullptr_t, 1024>, as dumb as it is,
go for it.
As things stand, GCC and Clang permit the use of 8-bit types in generators,
and I don't see a compelling reason to disallow it. The implementation
works and the wording can easily work.
Received on 2026-02-26 21:42:20
