[Cfp-interest 2074] AI about history of float and _Float32 being separate and distinct types.

[Jim Thomas]

Action item:
>     All: Look into the email history to find out why we chose to make float and _Float32 separate and distinct types.
> 


The first versions of Part 3 did not specify these aspects of the new types. Joseph Myers pointed this out as an issue. Parts of the ensuing email thread with Joseph and Jim are included at the end of this message.

We introduced the specification  “Interchange floating types are not compatible with any other types” (and the same for extended floating types) into the Part 3 draft between 20130304 and 20131204.

The March 2013 CFP minutes have: “Discussed significance of having distinct types, not compatible”.

The change to Part 3 was noted in a bullet in N1765, a slide deck used for a presentation for WG14.
 
My partial recollection is that we chose to make the types incompatible to:

	Potentially allow standard types to be non-IEC 60559, though Part 3 doesn’t cover this possibility.

	Allow designation of complex and imaginary types based on binary types in the same style as those based on standard types, for example, _FloatN _Complex instead of (typedef) _FloatN_complex.

	Avoid issues with _Generic. (?)

	Avoid issue (mentioned by Joseph) of possibly leading to double and long double (if both are decimal64) being compatible (which they aren’t).

	Avoid surprise limitations on the use of the new types.

How hard is it for a C/C++ compiler to treat the types as incompatible in C mode and differently in C++ mode?

- Jim Thomas

Emails:

++++++++++++++++++++++++
Jim Thomas
(SC22WG14.12854) interchange types, equivalence, basic types
To: "Joseph S. Meyers" <jsm at polyomino.org.uk> Cc: SC22 WG14 <sc22wg14 at open-std.org>

On Mar 7, 2013, at 11:53 AM, Jim Thomas <jaswthomas at sbcglobal.net <mailto:jaswthomas at sbcglobal.net>> wrote:

…

> On Mar 6, 2013, at 2:36 PM, Joseph S. Myers <jsm at polyomino.org.uk <mailto:jsm at polyomino.org.uk>> wrote:
> 
>> 
...
>> * There are references to such things as _Float32 being equivalent to 
>> float.  What does "equivalent" mean here?  The types could be the same 
>> type (like "long" and "long int").  They could be compatible types (like 
>> "int" and an enum for which the implementation-defined compatible integer 
>> type is int), but not the same.  They could be distinct (like "char" and 
>> "unsigned char", even if char is unsigned) but have the same 
>> representation and alignment.  Or one might imagine float having one 
>> endianness and _Float32 the other (both being binary32); is that intended 
>> to be ruled out?
> 
>> 
>> If various possibilities for whether types are the same / compatible / 
>> distinct but with the same values and (apart maybe from bit ordering) 
>> representation are intended to be allowed, I think the TS should make 
>> clear exactly what possibilities are permitted, rather than just using a 
>> vague "equivalent".
> 
> Their being the same type seems most direct. A possible problem is that this might allow more mixing of type nomenclatures and result in more confusing code. Also, if double and _Float64 were the same type and long double and _Float64 were the same type, then double and long double would be the same type, though they aren't.
> 
> 

Is there any reason to require a stricter sense of "equivalence" than in the following?

An implementation that defines __STDC_IEC_60559_BFP__ shall provide:
 _Float32 and _Float64 as interchange floating types with the same representation and alignment requirements as float and double, respectively
 _Float16 as a data-interchange type
and may provide:

_Float16 as an interchange floating type

If the implementation’s long double type supports an IEC 60559 interchange format of width N, then the implementation shall provide the type _FloatN as an interchange floating type with the same representation and alignment requirements as long double.


...
>> 
>> * Are all the new types basic / fundamental types, so that malloc must 
>> return memory suitably aligned for them (see my reflector message 12832 on 
>> 9 Jan for more on the issues there)?  C11 6.2.5#14 says "The type char, 
>> the signed and unsigned integer types, and the floating types are 
>> collectively called the basic types.", leaving open the question of 
>> whether data interchange types are also basic types.
> 
> Issue: how to assure that malloc can handle data-interchange types.
> 
> 

Any problem with including data-interchange types as basic types?

The type char, the signed and unsigned integer types, the floating types, and the data-interchange types are collectively called the basic types.


-Jim Thomas
++++++++++++++++++++++++

++++++++++++++++++++++++
Joseph S. Meyers
Re: (SC22WG14.12854) interchange types, equivalence, basic types
To: Jim Thomas <jaswthomas at sbcglobal.net> Cc: SC22 WG14 <sc22wg14 at open-std.org>
On Tue, 12 Mar 2013, Jim Thomas wrote:

> Is there any reason to require a stricter sense of "equivalence" than in 
> the following?

Well, I can't tell from that which of the options

* same type;
* distinct, compatible types;
* distinct types, not compatible

are allowed, and I think the definition needs to make clear which options 
are permitted to the implementation.

> Any problem with including data-interchange types as basic types?
> 
> The type char, the signed and unsigned integer types, the floating 
> types, and the data-interchange types are collectively called the basic 
> types.

I think defining these types as basic types should be OK.

-- 
Joseph S. Myers
joseph at codesourcery.com <mailto:joseph at codesourcery.com>
++++++++++++++++++++++++

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20210724/76fb43bd/attachment-0001.htm>