C++ Logo


Advanced search

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

From: Zhihao Yuan <zy_at_[hidden]>
Date: Tue, 25 Jun 2019 17:32:24 +0000
(I sent to the old list as well :(

On Tuesday, June 25, 2019 10:48 AM, Matthew Woehlke <mwoehlke.floss_at_[hidden]> wrote:
> [...] 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"

Your proposed behavior shows that they
conflate, while I agree that they shouldn't.

> [...] I hope folks
> will consider fixing this feature rather than nuking it entirely because
> a related feature was (mis)specified in terms of it.

You seem to suggest that the "internal" fill
is a feature that is independent from arithmetic
zero-padding. That is not the case. Here is
a copy of the paper proposed Iostreams for
inclusion in C++ [N0470 A Draft for the
Specification of the IOStream Classes], where



  The behavior of such functions [...], with the
  following alterations: [...]

  -- The formatted output function uses the fill
   character returned by fill() as the padding
   character(rather than the space character for
   left or right padding, or 0 for internal padding).

So the "internal" padding fill with 0 in early
Iostreams. I don't have access to the full
history, but apparently, from early designers'
point of view, internal padding as an independent
padding feature was not motivated. It is designed
to realize the 0 flag. Since we figured out that
it doesn't do the job well, then it should be
removed from new facilities, otherwise new users
can easily pick up the wrong tool.

Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.

Received on 2019-06-25 12:34:24