@facchinm, I also still have a version of this, including extended formatting, lying around that I need to finish up and document. If you're thinking on adding this, I could see if I can find some time soon to share that.

No hurry, take your time, I just posted it here to avoid losing all the tracks due to repo changes and issues being closed on the IDE repo

Is there anything you need from me? (It's been ages and I don't quite remember the code but I guess it won't be that hard)

I mostly need some time to clean things up and document things. Also, I'm not entirely sure that I'm happy with, the way variadic formatting can be customized right now (it does what it should, but it isn't entirely easy to customize things). Perhaps I should dig into that, document how it works now and we can have some discussion about how to improve on that...

Do you mean how the whole "two consecutive integers are interpreted as value + formatting" approach is extremely odd and hard to maintain? I feel the same way, but can't think of a better approach that doesn't break backwards compatibility.
Maybe it'd be better to move formatting entirely out of Print.h (except for very simple things, for the sake of backwards compatibility) to a separate "value formatter" class that does all the formatting work, and leave Print::print for simple multi-argument printing.

Do you mean how the whole "two consecutive integers are interpreted as value + formatting" approach is extremely odd and hard to maintain?

No, that is actually quite fenced off (only needs to be supported as the first two arguments).

What I mean is that in my code I have some ways to provide custom formatters and formatting objects, but that's a bit unwieldy to use (which also impacts the default formatting options, since those are just built-in custom formatters and options).

Maybe it'd be better to move formatting entirely out of Print.h (except for very simple things, for the sake of backwards compatibility) to a separate "value formatter" class that does all the formatting work, and leave Print::print for simple multi-argument printing.

I suspect this would mean that specifying formatting becomes more clunky, or more likely, significantly less efficient (having to construct intermediate objects and formatted values rather than writing them to a stream directly). Not entirely sure, though.

Also, this would cause a disconnect between the currently supported formatting options (base and precision) and any newly added options in terms of syntax.

@cousteaulecommandant, I created #34 for further discussion about formatting, since this is not strictly related to this PR.

We need this one 😍

Do you mean how the whole "two consecutive integers are interpreted as value + formatting" approach is extremely odd and hard to maintain?

No, that is actually quite fenced off (only needs to be supported as the first two arguments).

Why? I think it's perfectly reasonable to expect that Serial.println("var: 0x", var, 16) prints in hex.

Why? I think it's perfectly reasonable to expect that Serial.println("var: 0x", var, 16) prints in hex.

Don't worry, that's still supported. print("var: 0x", var, 16) will print "var: 0x" and then call print with the rest of the arguments (i.e., print(var, 16)), so we only need to care about the case for two leading numbers.

I was referring to the fact that it is a bit artificial that print("foo", "bar") prints foobar but print(16, 16) prints 10 and not 1616. (The feature makes sense and it's easy to document, just tell users not to print two consecutive integers and use print(16, "", 16) instead if they really want to concatenate integers; my concern was that the implementation was kind of messy.)

CLA assistant check
All committers have signed the CLA.

Not a maintainer. Just a reader of PRs.

I know the world has changed in the years this PR has been sitting here, but at some point, doesn't this become std::format ?

https://en.cppreference.com/w/cpp/io/print.html

That was formalized in C++23, but just barely missed the train in C++20. It's been in widespread use via the library for years before that. The syntax was popularized in Python and is generally well known in the industry. Compile-time argument checking and even performance optimizations being pushed into Templating syntax specifically to support these casese exactly because it is standardized. Arduino is unlikely to ever be able to assert such influence on the language standard.

https://isocpp.org/blog/2024/02/optimizing-the-unoptimizable-a-journey-to-faster-cpp-compile-times

Maybe this whole PR could reduce to an output iterator that expands into an Arduino::String and you gain programmer brain-compatibility with entrenched practices. (Those practices are now six years more entrenched than when this was submitted...)