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
>