C++ Logo

std-proposals

Advanced search

Re: [std-proposals] D2879R0 Proposal of Pythonesque std::print extensions LIVE LINK

From: Andrew Tomazos <andrewtomazos_at_[hidden]>
Date: Sat, 13 May 2023 19:25:16 +1000
On Sat, May 13, 2023 at 6:54 PM Jonathan Wakely <cxx_at_[hidden]> wrote:

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

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

Received on 2023-05-13 09:25:28