[Cfp-interest] format - subgroup meeting 20100204 notes

[Jim Thomas]

Please send me any corrections or additions.

-Jim

*** Notes from Formats subgroup meeting 04 Feb 2010 ***

Present were Liang-Kai, Fred, Mathew, Ian, Raymond, and Jim.

We discussed three topics (type names, character sequence conversions, 
and requiring binary128) and resolved related issues. NOTE: Subgroup 
members not attending the teleconference, please respond if you have 
concerns about these resolutions.


Type names:

RESOLVED: Not to include a real domain qualifier when designating real 
types. C doesn't use a domain qualifier for it's real types (float, 
double, long double). The longer real qualified names would be 
unnecessary and perhaps annoying, as the real types are used much more 
than the complex and imaginary ones.

RESOLVED: Use the existing C scheme to name complex and imaginary types 
in terms of their corresponding real types. Thus, for example, _Float256 
_Complex (two tokens). (C also allows placing the name of the associated 
real type last, e.g. _Complex _Float256.) This approach will be easier 
to specify and the specification will be easier to maintain. We had been 
on the track of using single token names in the belief that they would 
be better for C++, but any such issue already exists and implementations 
have dealt with it.

RESOLVED: The names for the decimal real types are _DecimalN. This 
matches the C decimal FP TR.

RESOLVED: The names for the binary real types are _FloatN. The 
alternative considered was _BinaryN. Arguments in favor of _FloatN are: 
it suggests floating types; the C float type is established as binary by 
Annex F and existing practice; __floatN is used by some implementations 
for binary floating types. Arguments in favor of _BinaryN are: it 
matches 754 terminology; it has better symmetry with _Decimal. We noted 
that 754 terminology is explicitly not intended to be a language binding.


Character sequence conversions:

RESOLVED: Pursue the approach of using conversions functions, along the 
lines Fred layed out in reflector email on 30 Jan 2010. We noted the 
advantages of referring to (rather than duplicating) existing C 
specification. Fred agreed to consider updating the proposal to leverage 
existing C specification.


Requiring binary128:

RESOLVED: Do not require support for binary128. Arguments in favor of 
this resolution include: in the absence of HW support, it would be a 
burden for implementors; implementors might think binary128 is not 
important for them; requiring binary128 might impede adoption of the TR; 
the market should decide. The argument for requiring binary128 is that 
unless binary128 is required programs that use it won't be portable 
across implementations that support our spec.