Date: Thu, 16 Sep 2021 23:42:56 +0200
(Removing LEWG; this feels like a core language question.)
On 16/09/2021 23.00, Matthias Kretz via Liaison wrote:
>
> 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.
Not good.
Remarkably, the result for "double" seems to be the other way round under N2601:
double + _Float64 = double
per section X.4.2 (page 10 line 17).
Did someone ask the C floating-point group whether that discrepancy
was intentional?
> Would it be an option to keep _Float32 and std::float32 distinct types?
That seems unhelpful. If those types have the same properties
(i.e. represent IEEE interchange types), they should be the
same from a type system perspective.
Jens
On 16/09/2021 23.00, Matthias Kretz via Liaison wrote:
>
> 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.
Not good.
Remarkably, the result for "double" seems to be the other way round under N2601:
double + _Float64 = double
per section X.4.2 (page 10 line 17).
Did someone ask the C floating-point group whether that discrepancy
was intentional?
> Would it be an option to keep _Float32 and std::float32 distinct types?
That seems unhelpful. If those types have the same properties
(i.e. represent IEEE interchange types), they should be the
same from a type system perspective.
Jens
Received on 2021-09-16 16:43:39