The community considers std::print a new and better replacement of std::cout, not an addition.

I suspect the difference between the proposed:


and the equivalent:

    std::cout << 1 << " " << 2 << " " << 3 << std::endl;

and their relationship to the Python:


is plain to see.

On Sat, May 13, 2023 at 1:13 PM Arthur O'Dwyer <> wrote:
I agree with Barry's assessment: this proposal doesn't match at all what Python does.
In Python, you never write
    print("%d %d", 1, 2)
    print("{} {}", 1, 2)
(and it wouldn't work if you did). Instead, you write
    print("%d %d" % (1, 2))
    print("{} {}".format(1, 2))

That is, the C++ equivalent of Python "print" is "cout", and the C++ equivalent of Python ".format" is "std::format".
    print("hello", 1, 2)
    std::cout << "hello" << 1 << 2;
(modulo whitespace and newline), and
    print("{} {}".format(1, 2))
    std::cout << std::format("{} {}", 1, 2);
(modulo newline).

The only point of `std::print` is to give us a terser syntax than the cumbersome `std::cout << std::format`.
Suppose you're trying to translate some Python code that uses `print` directly and doesn't use `.format`. Then in C++ you wouldn't use `std::format`, and therefore you wouldn't use `std::print` — you would just use the C++ equivalent of `print` (namely `std::cout`) directly.


On Fri, May 12, 2023 at 10:13 PM Andrew Tomazos via Std-Proposals <> wrote:

I actually misread the spec and thought it was UB if arguments were unused (so the compiler could catch it statically), so I didn't realize I was proposing a breaking change.

May I ask if you understand and support the motivation of the proposal?  And if so, can you think of a way to change the proposal to avoid the breakage while still achieving the goals?

I guess another thought I had would be whether "all that code" is already so much.  While it seems possible to have prints with unused arguments, it's unclear how often that feature is intentionally used (as opposed to accidentally used).  Maybe it's not too late to change it so that unused arguments have to be explicitly marked unused in some fashion (like something akin to [[maybe_unused]]) - and if so, the proposal would remain viable in the non-marked case.

Notice we could do this for print specifically, and wouldn't have to do it for the rest of the std::format applications.  I feel like the motivation applies specifically to std::print and std::println.


On Sat, May 13, 2023 at 11:28 AM Barry Revzin via Std-Proposals <> wrote:
One of the use-cases for {fmt} is to be able to translate the format string, and use the arguments in a different order. Sometimes that means some of those arguments may not even be used. That's why println("nwidgets:", 42) is a valid call today - it's just that the argument happens to not be used. This proposal would change the meaning of all of that code. Of the 5 examples, 3 are valid code today and would change meaning. 

Also if the premise is that println(x, y, z) just prints x then y then z, then having println("#{}:", 5, 6, 7) print "5: 6 7" doesn't really fit that goal at all. This isn't how print works in Python. 

We (all one of us) think this is a bad idea. 


On Thu, May 11, 2023 at 7:55 AM Victor Zverovich via Std-Proposals <> wrote:
I think overloading print to either take or not take a format string is not a good idea because it subtly changes code semantics depending on whether the first argument is a string or not. If you pick a different name for the functionality you are proposing then I won't be opposed but not particularly interested in this either because the usability benefits are minimal.


On Wed, May 10, 2023 at 10:23 PM Andrew Tomazos via Std-Proposals <> wrote:
Please find below a LIVE LINK to a short 2-page proposal:

D2879R0 Proposal of Pythonesque std::print extensions

We propose extensions to std::print/ln such that the format string is automatically deduced and/or extended from the arguments to std::print/ln - in a similar fashion to the existing practice of the Python `print` function, and like other similar functions from other languages.

Feedback appreciated,


Std-Proposals mailing list
Std-Proposals mailing list
Std-Proposals mailing list
Std-Proposals mailing list