Re: An even better implementation of 22.2.6.2.2 ??

[Martin Sebor <sebor at roguewave dot com>]

Nathan Myers wrote:
> 
...
> Before we get into opinions, let me summarize:
> 
> 1. The standard is clear that if the format pattern contains a "space",
>    then the resulting character sequence includes an actual space
>    character.

I don't think it's clear, especially in light of (3) :)

> 
> 2. The standard is clear that if the width requires padding, the fill()
>    characters are placed adjacent to this space (if any).

I agree.

> 
> 3. Various implementers (apparently including Dinkumware, Metrowerks,
>    and Rogue Wave) have misread the standard and shipped nonconforming
>    variations, such as omitting the space when the currency symbol is
>    suppressed, or using the fill character in place of the space.

Also agreed, but I think Benjamin and/or Paolo may have had some
questions about the text, so it seems that every implementer I know
other than yourself read it wrong.

> 
> 4. The standard is entirely mute on the subject of whether the fill
>    characters (if any) appear before or after the space (if any).
> 
> If we are only interested in conformance, it is easy: insert a space
> where indicated, and choose arbitrarily whether to insert fill characters
> before it or after it.
> 
> Interoperability is harder.  The monetary formats were meant to be
> strictly specified because interpretation errors where monetary values
> are involved could cause big trouble.  Too much slack in the spec would
> be a defect by that criterion.  Can a user write code that will generate
> output that can safely be read by any other implementation?  If the fill
> character is other than (' '), there is no expectation anyhow. 

I realize these are corner cases but the fill character could be a digit
or any other character that changes the meaning of the monetary value
without making it unparsable. Given how important precise formatting
of monetary values is, I would feel better if their behavior was clearly
specified in this case as well.

...
> 
> We should prepare a Defect Report for the committee.  Of course there's
> no telling what they will do with it, but usually they will either say
> "not a defect", blessing all interpretations, or pick one to bless.

If you're going to be proposing changes, it seems simple enough to also
clarify (1) and (4). I'd be glad to help work on the wording.

Martin