Output Ranges for Functionality & Additional Safety #3756
Conversation
— 💡 MSVC fixed this linker errors (at some point); should check for newer versions and just use the char32_t-based version properly.
- format_to(some_char_array, ...) will now do the right thing for the most part, and also supports appending to existing ranges (using the same conceptual ideals as as std::ranges::to) - The API for format_to is a bit complicated since we do appending and also pass/support all the existing iterator-based use cases. - format_into is a cleaner API that accepts ranges and output iterators, and does not do appending for those ranges that it recognizes (just fills in the `[begin, end)`). This is necessary to avoid strange behaviors on whether or not a container may or may not meet the appending requirements (e.g., more consistent in generic code). - We lose a lot of compile-time performance with how we're checking things now, so not the best job we could be doing.... - Much of that compile-time performance can be gained back with more rigorous return-style enable_if and such, but that is beyond my work - Actual performance for the calls themselves are only marginally smaller for pointer-based iterators (fmt is, internally, lacking continguous iterator support. Counterpoint; buffers are the only case that matters! (this is a bit of a lie lmaoo))
ThePhD
force-pushed
the
thephd/output-ranges
branch
from
a5e985f
to
4533970
Compare
…ather than 16.0.x)
There was a problem hiding this comment.
Thanks for the PR!
Improving safety for the array of known bound case sounds reasonable but unfortunately there are too many problems with the proposed implementation (and to some extent design) so it will require major changes. The most obvious one is that it is a fairly big breaking change. Fortunately there are ways to redesign this to make it less breaking.
You mentioned that you don't intend this to be merged so I'm a bit confused with what the plan here is. But if you change your mind, the first thing to do would be to split this into three PRs:
- Handling the array of known bound in
fmt/core.hwithout introducing a dependency on ranges and making any changes below the buffer layer. - Handling the array of known bound in format string compilation. This needs complete redesign but we could start with the context hack and iterate.
- Adding the new (output) ranges API in
fmt/ranges.h. You'll need to provide motivation for the changes there.
|
Ah, making the changes to the format string compilation might be fully beyond my understanding at the moment. But, otherwise, I (think?) I can successfully split the changes into different overloads over multiple files again with the only range stuff in the top-level. I'll PR the known-bound for
More of a proof of concept that this can be done, rather than asserting it should be. There's design motivation as to why this should be done but that's an entire C++ proposal, which I think is actually bigger and more involved than I could ever fit in this PR. Even as I chunk this into pieces to make it more acceptable, I'd like to keep this PR here still as a proof that we passed the existing tests and didn't break any of the tested use cases. (At least, not anything picked up by the tests or compilation of said tests, anyways.) |
You actually did it already by changing
Do you have a paper number for this proposal? |
|
Closing since this PR is not intended for merging. |
The following snippet will overrun a too-small buffer:
This pull request changes that by turning all places that took
OutputItwithformat_toto useOutput&&instead and use the concept ofoutput_rangesORoutput_iterator, where appropriate.This PR is not intended to make it into mainline
{fmt}, just to prove it is possible to do so and pass all the tests to show it doesn't break the existing interfaces.