[Cfp-interest] format - type names issue

[Jim Thomas]

 >> Issue: What type names to use? Alternatives:
 >>
 >> 1 _BinaryN
 >>   _DecimalN
 >>   _BinaryN_Complex
 >>   _DecimalN_Complex
 >>   _BinaryN_Imaginary
 >>   _DecimalN_Imaginary
 >>
 >> 2 _FloatN
 >>   _DecimalN
 >>   _FloatN_Complex
 >>   _DecimalN_Complex
 >>   _FloatN_Imaginary
 >>   _DecimalN_Imaginary
 >>
 >> 3 _Real_BinaryN
 >>   _Real_DecimalN
 >>   _Complex_BinaryN
 >>   _Complex_DecimalN
 >>   _Imaginary_BinaryN
 >>   _Imaginary_DecimalN

1 and 2 are more in the style of the existing C floating types. C 
doesn't qualify the names of floating types with "real". It's just float,
not "real float" or "float real". The imaginary and complex types can be 
thought of as constructed from their corresponding real types, so it 
makes sense to explicitly name the domain for imaginary and complex but 
not for real. I'm unaware of any confusion caused by this naming approach.

99.9[...]% of programs and programmers will deal only with real types. 
Programmers wouldn't thank us for lengthening the names of the real 
types (as with 3):

_Real_Binary256 fmab256 (_Real_Binary256, _Real_Binary256, _Real_Binary256);

vs

_Float256 fmaf256 (_Float256, _Float256, _Float256);

3 is inconsistent with the existing C decimal FP TR (_Real_DecimalN vs 
_DecimalN). This would mean that current implementations of the TR would 
need to support two naming schemes for their decimal floating types.

_FloatN is easily thought of as the binary floating type of width N. The 
existing C float type must be binary for Annex F (IEEE) implementations 
and is binary in almost all implementations. Existing implementations 
(including gcc) currently use __floatN to designate binary floating 
types (__float80, __float128). I'm unaware of any C history that would 
associate _BinaryN with floating point.

I think this argues that 2 is the best choice.

-Jim