Date: Thu, 16 Sep 2021 23:00:53 +0200
On Wednesday, 15 September 2021 20:38:27 CEST Aaron Ballman via Ext wrote:
> On Wed, Sep 15, 2021 at 2:27 PM Jens Maurer via Ext
>
> <ext_at_[hidden]> wrote:
> > On 15/09/2021 20.12, Joseph Myers via Liaison wrote:
> > > On Wed, 15 Sep 2021, Thomas Köppe via Liaison wrote:
> > >> - Currently, the new types are *exclusively* available in the
> > >> _Reserved_name spelling (like "_Bool" was in C99), there is no set
> > >> of
> > >> "pretty" macros (like "bool" was in <stdbool.h>) -- that means that
> > >> if C++
> > >> decides to introduce new pretty names like (std::)float16_t, we have
> > >> no
> > >> immediately interoperable name (like "float16_t") that would be
> > >> valid C,
> > >> since there is no macro "#define float16_t _Float_16", say.
> > >
> > > Also, note that C *does* have typedef names such as _Float16_t - that's
> > > a
> > > type whose range and precision are used for evaluating operations on
> > > type
> > > _Float16, analogous to float_t and double_t.
> > >
> > > I suggest it would be confusing for float16_t to mean something
> > > different
> > > from _Float16_t, and so float16_t may not be a good name to use to mean
> > > _Float16 in C++.
> >
> > Is there an actual document that specifies exactly what
> > the additional C floating-point support is?
> >
> > The TS does not seem to be freely available.
>
> http://www.open-std.org/jtc1/sc22/wg14/www/projects#18661 lists the
> latest drafts before they were rolled into the TS.
Thanks. AFAICS, Part 3 (which defines the new floating-point types) of the TS
has not been applied to the latest published C23 WD. But http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2601.pdf proposes the merge.
After reading Section 8 "Conversions" in N2601 (WG14), I believe std::floatN_t
and _FloatN need to be distinct types anyway. P1467R4 says "The proposed usual
arithmetic conversions when mixing different floating-point types are
essentially the same in both languages". But I read it differently:
float + _Float32 -> _Float32
float + std::float32 -> float.
Oh and with "binary80" C23 yields:
long double + _Float64x -> long double
Whereas P1467 doesn't cover IEC 60559 extended formats, right?
Would it be an option to keep _Float32 and std::float32 distinct types?
> On Wed, Sep 15, 2021 at 2:27 PM Jens Maurer via Ext
>
> <ext_at_[hidden]> wrote:
> > On 15/09/2021 20.12, Joseph Myers via Liaison wrote:
> > > On Wed, 15 Sep 2021, Thomas Köppe via Liaison wrote:
> > >> - Currently, the new types are *exclusively* available in the
> > >> _Reserved_name spelling (like "_Bool" was in C99), there is no set
> > >> of
> > >> "pretty" macros (like "bool" was in <stdbool.h>) -- that means that
> > >> if C++
> > >> decides to introduce new pretty names like (std::)float16_t, we have
> > >> no
> > >> immediately interoperable name (like "float16_t") that would be
> > >> valid C,
> > >> since there is no macro "#define float16_t _Float_16", say.
> > >
> > > Also, note that C *does* have typedef names such as _Float16_t - that's
> > > a
> > > type whose range and precision are used for evaluating operations on
> > > type
> > > _Float16, analogous to float_t and double_t.
> > >
> > > I suggest it would be confusing for float16_t to mean something
> > > different
> > > from _Float16_t, and so float16_t may not be a good name to use to mean
> > > _Float16 in C++.
> >
> > Is there an actual document that specifies exactly what
> > the additional C floating-point support is?
> >
> > The TS does not seem to be freely available.
>
> http://www.open-std.org/jtc1/sc22/wg14/www/projects#18661 lists the
> latest drafts before they were rolled into the TS.
Thanks. AFAICS, Part 3 (which defines the new floating-point types) of the TS
has not been applied to the latest published C23 WD. But http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2601.pdf proposes the merge.
After reading Section 8 "Conversions" in N2601 (WG14), I believe std::floatN_t
and _FloatN need to be distinct types anyway. P1467R4 says "The proposed usual
arithmetic conversions when mixing different floating-point types are
essentially the same in both languages". But I read it differently:
float + _Float32 -> _Float32
float + std::float32 -> float.
Oh and with "binary80" C23 yields:
long double + _Float64x -> long double
Whereas P1467 doesn't cover IEC 60559 extended formats, right?
Would it be an option to keep _Float32 and std::float32 distinct types?
-- ────────────────────────────────────────────────────────────────────────── Dr. Matthias Kretz https://mattkretz.github.io GSI Helmholtz Centre for Heavy Ion Research https://gsi.de stdₓ::simd ──────────────────────────────────────────────────────────────────────────
Received on 2021-09-16 16:01:00