On Wed, Jan 31, 2024 at 4:47 PM Thiago Macieira via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Wednesday, 31 January 2024 06:50:20 PST Arthur O'Dwyer via
> Std-Proposals wrote:
> > I don't necessarily object to providing a std::bit_int<N> alias in some
> > standard header; but I would very much like to be able
> > - to use `_BitInt` in C++ programs *in the core language*, without
> > including any standard headers;
>
> Why? You can't use std::uint64_t without <cstdint>, std::float16_t without
> <stdfloat> and even std::nullptr_t without <cstddef>.
>

std::uint64_t is just a typedef for the actual type. I can use the actual
type (e.g. `unsigned long`) in the core language, no problem.
std::nullptr_t is just a typedef for the actual type. I can use the actual
type in the core language, no problem (although it must be spelled
`decltype(nullptr)`).

std::float16_t is new to me. I see <stdfloat>
<https://en.cppreference.com/w/cpp/header/stdfloat> just arrived in C++23.
Looks like that's a very close analogue to _BitInt, so for consistency that
might be the way to go (i.e. my position may be doomed already). For
example, std::float16_t is an alias for _Float16
<https://en.cppreference.com/w/cpp/types/floating-point#Fixed_width_floating-point_types>,
but the name "_Float16" appears only in this *Recommended Practice* note:

https://eel.is/c++draft/basic.extended.fp#7
> Recommended practice: Any names that the implementation provides for the
extended floating-point types described in this subsection
> that are in addition to the names defined in the <stdfloat> header should
be chosen to increase compatibility and interoperability
> with the interchange types _Float16, _Float32, _Float64, and _Float128
defined in ISO/IEC TS 18661-3
> and with future versions of ISO/IEC 9899.

This can be read as passive-aggressive encouragement for the vendor to
"provide [a name for _Float16] in addition to the names defined in the
<stdfloat> header" that's independent of that header at all, i.e., a
(possibly core-language) name for _Float16, which has been "chosen to
increase compatibility" with C, where C's name for that type is _Float16 —
i.e., passive-aggressive encouragement for the vendor to provide the name
_Float16 in the core language. It doesn't actually *say* it, but it can be
read as *encouraging* it.
I'm not thrilled with passive-aggressive word puzzles in the Standard, but
I know it's par for the course, and it wouldn't make me any *less* happy if
_BitInt were handled in the same way as _Float16. :)

Even more closely, you need <atomic> for std::atomic<T>, as _Atomic(T) is
> not
> part of the C++ language (though your compiler probably allows it).
>

Well, std::atomic<T> is a class type, with a lot of member functions and
stuff. I don't expect a complicated class type like std::atomic,
std::complex, std::string, or std::regex to be usable in the core language.
But for an *integral type*, something for which std::is_class_v<T> returns
false, I'd hope it was usable in the core language.


> - to use the same syntax for `_BitInt(N)` in both C and C++ (e.g. in
> header
> > files shared between languages, without adding extra #ifdefs)
>
> In this case, that's a valid request, but then just use the C syntax and
> assume your C-and-C++ compiler does support that in C++ mode. Headers that
> work in C are not part of the C++ language.
>

"Then just use the C syntax and assume your C++ compiler supports it" —
Right, that's obviously the game plan in practice. I'm saying that since we
all know that's the game plan in practice — couldn't the Standard admit it,
too?
See also my cynical (but realistic) complaint that if the Standard says
"Standard C++ assigns no meaning to the reserved word _BitInt," then the
Clang maintainers will take it upon themselves to issue a diagnostic
whenever the word "_BitInt" is uttered in -std=c++XY mode. That makes work
for everybody involved.


> Is stdio.h part of the C++ standard?
>

Yes; see https://eel.is/c++draft/support.c.headers.general
But, to be clear, here I was talking about the contents of user-defined
header files ("mylibrary/mything.h"), not standard headers.

> - to be able to express `unsigned _BitInt(N)` by putting the token
> > `unsigned` next to the name of the type, instead of by wrapping it in
> > `std::make_unsigned_t` (which again requires including a standard header)
>
> But the converse doesn't apply: you can't make_signed by adding a "signed"
> to
> where an "unsigned" is already present.
>

True.

–Arthur