Hi Dimitrij,

Thanks for the feedback. You are right that the normal ostream error
handling mechanism should apply here. This will be clarified in the next
revision of the paper.

Cheers,
Victor

On Thu, Feb 3, 2022 at 2:53 PM Dimitrij Mijoski <dim.mj.p_at_[hidden]> wrote:

> First I'll say that fmt::print(ostream&) does the right thing and just
> calls ostream.write.
>
> https://github.com/fmtlib/fmt/blob/35c0286cd8f1365bffbc417021e8cd23112f6c8f/include/fmt/ostream.h#L55-L67
> But in the paper wording, things arent exactly clear.
>
> The paper says
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2093r12.html#wording
>
> > void vprint_nonunicode(ostream& os, string_view fmt, format_args args);
> >
> > 4 Effects: Writes the result of vformat(os.getloc(), fmt, args) to os.
> >
> > Throws: As specified in [format.err.report] or system_error if a call
> > by the implementation to an operating system or other underlying API
> > results in an error that prevents the function from meeting its
> > specifications.
>
> Iostreams have their own error handling mechanisms with their 3 error
> flags. They can even throw exceptions if one opts-in. All IO functions
> follow the same convention regarding these flags, and std::print that
> accepts ostream should probably follow
> it. https://en.cppreference.com/w/cpp/named_req/UnformattedOutputFunction
> The easiest way is to just call ostream.write() like in fmtlib.
>
> I'm writing this because with the current wording I get the impression
> that system_error should be thrown if failbit gets set (or even if it
> was set before the call to std::print). That exception should be used
> only when some C APIs return error like WriteConsoleW() on Windows.
>
>