Just my two cents, fwiw...

Seems the core problem with printf is that the stack contains no type
information.

A solution could be a func decl keyword "typed" for funcs that take
variadic arguments. The compiler then includes type info for each such arg.
The function's use of va_list (probably a new kind like va_typed_list) then
lets it access that info.

Ray


On Sun, Mar 12, 2023 at 2:25 PM Thiago Macieira via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Sunday, 12 March 2023 11:25:43 PDT Robin Rowe via Std-Proposals wrote:
> > 1. Not practical to rewrite legacy C/C++ code containing a zillion
> > printf statements.
>
> True, but irrelevant and counterweighed. First, you need to weigh that
> against
> the work that is required to get printf() to do what you're suggesting. I
> have
> serious doubts it can even be made to do what you want in C, and if it's
> for
> C++ only, then you'll have to justify why the standards team and the
> compiler
> developers should spend time on printf for C++.
>
> Second and most importantly, your statement is irrelevant. The zillions of
> printf() statements are, in their vast majority, already working. No one
> is
> going to go and touch them because we've got a new-fangled printf. If they
> are
> using that in C++, at the next refactoring opportunity, they should update
> to
> std::format and std::print, dispensing of the printf() code in the first
> place.
> It stands to reason that any code able to benefit from
> C++29-newfangled-printf
> has been able to benefit from std::print for longer.
>
> And those that aren't strictly correct may still work for the purposes and
> constraints they are found themselves in, so they may not be able to
> update to
> the new API.
>
>
> > 2. Building embedded systems and game servers, we may want to avoid
> > std::string due to heap global lock.
>
> Sorry, I don't buy this argument either.
>
> First, you're comparing the cost of std::printf to the cost of FILE*. Both
> have a cost, but you're making a judgement call here that one is
> preferable to
> the other, without giving arguments as to why. I think printf() is allowed
> to
> memory behind the scenes.
>
> And if it can work without memory allocations and use only the already-
> allocated stdout buffer, then why can't std::print do the same?
>
> Second, what global lock? Maybe you should invest in a better memory
> allocator
> instead? For an embedded system where the number of threads may be
> statically
> know, it's perfectly possible to have a working malloc() without global
> locks.
>
> Third, you're assuming that a type-safe C++ printf() would avoid the
> problem
> you're alluding to, but again you don't prove that. At a minimum, you'd
> have
> to show that this implementation is possible-easy for std::printf() and
> unliekly-difficult to std::print().
>
> > It's not that we lack more modern approaches for type-safe printing such
> > as std::iostream, std::format or std::print. It's that a small change to
> > printf could make legacy code maintenance and embedded systems
> > development better.
>
> What makes you think that it's a small change to printf? Have you actually
> implemented it and proven that it is so?
>
> If so, please provide a link to your repository with the proof of concept.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel DCAI Cloud Engineering
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>