P754 draft 1.8.0

[Michel Hack <hack@xxxxxxxxxxxxxx>]

I'm not extatic about the way Clause 7.6 was resolved, but it'll do.
My other objections were all dealt with.

I notice two changes in substance:

(1) Hexadecimal strings.

In 5.4.3 support for hexadecimal strings became optional.  I have no
strong feelings:  exact binary values can still be specified, provided
the target binary format is known -- which is usually the case in such
situations.  That's because decimal-strings are now required to be
converted with correct rounding.  There is one problem area however,
and that is those extendable formats of Clause 3.7.  Perhaps we should
consider conditionally-required support:

    If extendable-precision binary formats are supported, conversion
    from hexadecimal strings must be supported.

The problem also exists if a large number of extended formats are
supported, because each one requires a different decimal string to
arrive at the same binary value -- unless H is unbounded, and the
programmer does not mind entering the EXACT decimal value.


(2)  preferredWidth (what widenTo evolved into, via minWidth)

In 10.3 the requirement for radix-specific preferredWidth was removed.
This may be ok (and even good) for preferredWidthFormat, but it is unclear
how this applies to preferredWidthFormat.  If the latter is implemented
as an attribute with a value, e.g. a type name, there should definitely
be two attributes, preferredWidthBinary and preferredWidthDecimal.  If the
intent is to have a set of boolean attributes like preferredWidthBinary64,
then it should be clear that either the preferredWidthNone, or one of the
preferredWidthFormat attributes for each radix, be asserted.  If none is
asserted, the language presumably defines the default, and if conflicting
attributes are set, presumably an error would be reflected.

I would have much preferred an exposition that states that the notion of
preferred width must be controllable, without delving into the details,
but I suppose there was a desire to fit this into an environment where
groups of modes can be controlled, perhaps saved and restored, using a
common set of interfaces.


I also have a question about the new Note at the end of 5.4.1, which
states that some operations can be implemented as sequences of others
as long as the result and exceptions are the same.  Is that not generally
the case anyway?  Why single out the conversion operations?


Michel.
Sent: 2008-04-09 12:03:05 UTC