People will get used to how C++ print works. Possible names for format-less (debug) output:   std::display -> Matlab disp(), Python Jupiter display() std::show std::output std::trace std::echo -> php, shell commands std::report std::printvals std::view used std::ranges::view std::put used std::write used   -----Ursprüngliche Nachricht----- Von:Andrew Tomazos via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Sa 13.05.2023 11:25 Betreff:Re: [std-proposals] D2879R0 Proposal of Pythonesque std::print extensions LIVE LINK An:Jonathan Wakely <cxx_at_[hidden]>; CC:Andrew Tomazos <andrewtomazos_at_[hidden]>; C++ Proposals <std-proposals_at_[hidden]>;   On Sat, May 13, 2023 at 6:54 PM Jonathan Wakely <cxx_at_[hidden] <mailto:cxx_at_[hidden]> > wrote: On Sat, 13 May 2023, 03:13 Andrew Tomazos via Std-Proposals, <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > wrote: Barry,  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?  A tag type in place of the format string: std::print(auto_fmt, 1, 2, 3);  Which would also extend to: std::print(file, auto_fmt, 1, 2, 3);  I think it defeats the motivation if the supposedly quick and easy version is a mouthful.  Or use a completely different name for "print with implicit format string" instead of overloading std::print.  I like this idea, but I can't actually think of a good alternative name.  I really think we screwed up the name of C++23 std::print.  If it was intended to always take an explicit format string as the first argument, it should at least have f for format somewhere in its name or context.  That seems to be the existing practice from other languages (and I guess we can include C in that convention with `printf`).  I'm somewhat surprised LEWG didn't see it that way.  Maybe `std::printa` where the a is for Auto-formatted, and `std::printaln`.  I dunno.    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.  Thanks, Andrew.   On Sat, May 13, 2023 at 11:28 AM Barry Revzin via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > 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.   Barry On Thu, May 11, 2023 at 7:55 AM Victor Zverovich via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > 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.  Cheers, Victor On Wed, May 10, 2023 at 10:23 PM Andrew Tomazos via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > wrote: Please find below a LIVE LINK to a short 2-page proposal:  D2879R0 Proposal of Pythonesque std::print extensions https://docs.google.com/document/d/1E5y_osldYmdBYxUQh8sBlGIEOxJ0FoRiXAJaJD4XATQ  > 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, Enjoy, Andrew. -- Std-Proposals mailing list Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals -- Std-Proposals mailing list Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals -- Std-Proposals mailing list Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals -- Std-Proposals mailing list Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals