On Fri, Dec 15, 2023 at 4:43 AM Jonathan Wakely <jwakely@redhat.com> wrote:

> On Fri, 15 Dec 2023 at 01:17, Tim Song wrote:
> >
> > On Thu, Dec 14, 2023 at 6:05 PM Jonathan Wakely <jwakely@redhat.com>
> wrote:
> >> +  inline void
> >> +  vprint_unicode(ostream& __os, string_view __fmt, format_args __args)
> >> +  {
> >> +    ostream::sentry __cerb(__os);
> >> +    if (__cerb)
> >> +      {
> >> +
> >> +       const streamsize __w = __os.width();
> >> +       const bool __left
> >> +         = (__os.flags() & ios_base::adjustfield) == ios_base::left;
> >
> >
> > I'm pretty sure - when I wrote this wording anyway - that the intent was
> that it was just an unformatted write at the end. The wording in
> [ostream.formatted.print] doesn't use the "determines padding" words of
> power that would invoke [ostream.formatted.reqmts]/3.
>
> Ah, OK. I misunderstood "formatted output function" as implying
> padding, failing to notice that we need those words of power to be
> present. My thinking was that if the stream has padding set in its
> format flags, it could be surprising if they're ignored by a formatted
> output function. And padding in the format string applies to
> individual replacement fields, not the whole string, and it's hard to
> use the stream's fill character and alignment.
>

But we would get none of the Unicode-aware padding logic we
do in format, which puts it in a very weird place.

And for cases where Unicode is not a problem, it's easy to get padding
with just os << std::format(...);


> You can do this to use the ostream's width:
>
> std::print("{0:{1}}", std::format(...), os.width());
>
> But to reuse its fill char and adjustfield you need to do something
> awful like I did in the committed code:
>
> std::string_view align;
> if (os.flags() & ios::adjustfield) == ios::right)
>   align = ">"
> auto fs = std::format("{{:{}{}{}}}", os.fill(), align, os.width());
> std::vprint_nonunicode(os, fs, std::make_args(std::format(...)));


> And now you have to hardcode a choice between vprint_unicode and
> vprint_nonunicode, instead of letting std::print decide it. Let's hope
> nobody ever needs to do any of that ;-)
>

At least the upcoming runtime_format alleviates that :)


>
> I'll remove the code for padding the padding, thanks for checking the
> patch.
>
>