Internal fill *not* considered harmful (re: P1652)

[Matthew Woehlke]

(Should this sort of comment be raised on the github issue, instead,
these days? Is there an expectation how discussion on github issues that
correspond to papers should be used? Also, someone may want to forward
this to the internal LEWG reflector, to which I am not subscribed and
don't have the address...)

Looking at the C++-targeted papers, I noticed that P1652 proposes
removing the '=' alignment specifier, citing this problematic use case:

std::string s1 = std::format("{:0=6}", nan); // s1 == "000nan"

However, I don't think this is a problem; it is doing exactly what the
code author asked. In particular, note:

std::string s1 = std::format("{:%=6}", -inf); // s1 == "-**inf"
std::string s1 = std::format("{:%=+6}", inf); // s1 == "+**inf"

I think the problem is really with P0645's statement: "This is
equivalent to a fill character of '0' with an alignment type of '='."

It isn't internal alignment that is the problem, it's treating the
special case of width.starts_with('0') as equivalent to '0=':

std::string s2 = std::format("{:06}", nan); // s2 == "000nan"; bad!

P1652 *correctly* proposes to make this follow C99:

std::string s2 = std::format("{:06}", nan); // s2 == " nan"

However, this also illustrates that fill and arithmetic zero-padding
aren't precisely the same thing and shouldn't be conflated. In
particular, IMHO the following would be correct behavior:

std::string s2 = std::format("{:*<06}", 123); // s2 == "000123"
std::string s2 = std::format("{:*<06}", nan); // s2 == "***nan"

I won't be at Cologne (hoping to make Belfast though), but I hope folks
will consider fixing this feature rather than nuking it entirely because
a related feature was (mis)specified in terms of it.

Instead, I would humbly suggest the following wording:

Preceding the width field by a zero ('0') character pads leading zeros
(following any indication of sign or base) to the field width, except
when applying to an infinity or NaN. This option is only valid for
arithmetic types other than charT and bool or when an integer
presentation type is specified. If the ‘0’ and an align option both
appear, **this padding is applied prior to any other alignment and
filling.**

(Emphasis indicates changes vs. P1652's proposed wording.)

--
Matthew

[Jens Maurer]

On 25/06/2019 17.48, Matthew Woehlke wrote:
> (Should this sort of comment be raised on the github issue, instead,
> these days? Is there an expectation how discussion on github issues that
> correspond to papers should be used? Also, someone may want to forward
> this to the internal LEWG reflector, to which I am not subscribed and
> don't have the address...)

The github paper tracker is exclusively for organizational concerns.
Any technical concerns should be raised on the appropriate reflectors
or by e-mailing the paper author.

So, ok for the issue tracker:
- pointing out that paper X was applied, but the issue was not closed
- pointing out that the labels are wrong.
- pointers to related papers
- pointers to discussion notes on the reflector or the wiki
- summaries of votes (added by the subgroup chairs)

Not ok for the issue tracker:
- technical discussion

So, please e-mail the paper author(s) with your concerns.

Jens