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
>