On Sat, 13 May 2023, 03:13 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?
>

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);

Or use a completely different name for "print with implicit format string"
instead of overloading std::print.



> 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
>