C++ Logo

std-proposals

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

  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1994/N0470.asc

states:

  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