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

I suspect the difference between the proposed:

    std::println(1,2,3);

and the equivalent:

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

and their relationship to the Python:

    print(1,2,3)

is plain to see.


On Sat, May 13, 2023 at 1:13 PM Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
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)
> becomes
> std::cout << "hello" << 1 << 2;
> (modulo whitespace and newline), and
> print("{} {}".format(1, 2))
> becomes
> 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.
>
> –Arthur
>
>
> On Fri, May 12, 2023 at 10:13 PM Andrew Tomazos via Std-Proposals <
> 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?
>>
>> 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]> 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]> 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]> 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]
>>>>> 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
>>>>
>>> --
>>> Std-Proposals mailing list
>>> 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
>>
>