Hi Andrew,

you were suggesting to use std::put

But there is already an basic_ostream::put member function.

https://en.cppreference.com/w/cpp/io/basic_ostream/put

The std::print and std::println functions have been provided as free functions and as basic_ostream member functions for good reasons (having a default stream and an individual stream).

One would probably want to do the same for an type-autodetecting print function.

put could have lots of existing code, which outputs a char by number, e.g. std::cout.put(65)

The question I stated at the end, is, whether puts can be safely used as std::puts free function and overloaded basic_ostream::puts member function instead.

The existing std::puts expects a const char* argument.

One (important?) difference between the existing std::puts(const char*) and std::print is that the former returns an implementation-defined int value, the latter is void.

Probably choosing a different name is the overall 'safer' option.

Then one is free to define, how const char* is printed, e.g. as this feature probably is most useful for debug output, one could rule, that all pointers print their address and the contents in a type-dependent way.

But this could also be two different requirements or two different functions, one for pretty default printing, one for information-rich debug printing.

Best,

Sebastian

-----Ursprüngliche Nachricht-----
Von: Andrew Tomazos <andrewtomazos@gmail.com>
Gesendet: Di 16.05.2023 11:09
Betreff: Re: [std-proposals] D2879R0 Proposal of Pythonesque std::print extensions LIVE LINK
An: std-proposals@lists.isocpp.org;
CC: Sebastian Wittmeier <wittmeier@projectalpha.org>;

On Mon, May 15, 2023 at 1:30 AM Sebastian Wittmeier via Std-Proposals <std-proposals@lists.isocpp.org> wrote:

std::cout.put(65) writes "A"

So not compatible.

puts("65") expects a pointer and writes "65\n"

 

For print and println ostream-members have been created in addition to free std::print and std::println, and it would make sense for such an autodetecting function.

 

puts has string in its name and would be illogical to auto-detect other types. One can reason it would convert to string.

 

Would it be safe and continue to work with any current use?

 

I don't understand the question.  Would what be safe? and continue to work with the current use of what?  Continue to work after what event?