Our implementation of std::format assumed that string_view's iterators
were raw pointers in various places. If we want to introduce a checked
iterator in debug mode, that won't be true anymore. This patch removes
that assumption.
Details
- Reviewers
Mordante - Group Reviewers
Restricted Project - Commits
- rG1562e5149174: [libc++] Don't assume that string_view::const_iterator is a raw pointer
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
@Mordante Please let me know if you like this approach. In a few places, we have the choice of blindly taking _Iterator or explicitly stating basic_string_view::const_iterator -- let me know what you prefer and I'll change it.
Nice catch, I thought the iterators were required to be character pointers, but they indeed are not. So I feel this it the better way to do it. (Unless we want to "unwrap our iterators" in the top-level format functions.)
In general I like the approach, but I left some comments. I really think we should constrain the iterator types since the code makes assumptions on which operations are allowed.
Otherwise LGTM!
libcxx/include/__format/format_string.h | ||
---|---|---|
33 | The current name is misleading after the change. The original name was based on <charconv> which uses char pointers. When switching to iterators I prefer to use a more generic name. | |
104 | I think it would be good to add consistent constrains to _Iterator. This line requires a random access iterator. | |
libcxx/include/__format/formatter_output.h | ||
255–257 | In combination with the next suggestion. | |
260 | Wouldn't this work? | |
271 | Likewise. |
libcxx/include/__format/formatter_output.h | ||
---|---|---|
260 | Yes it would work, but don't you feel like it's more readable to introduce a separate name for the type? |
libcxx/include/__format/formatter_output.h | ||
---|---|---|
260 | My main concern it that by giving the type a name, it's intended to be configurable by the caller, which isn't intended. |
libcxx/include/__format/formatter_output.h | ||
---|---|---|
282 | I stumbled upon this, but this is never tested with non-char* iterators, it seems. Same for a few functions below. It is probably worth investigating to add some test coverage. |
CI issues seem unrelated, shipping since @Mordante was happy with a prior version and I addressed the remaining comments.
The current name is misleading after the change.
The original name was based on <charconv> which uses char pointers. When switching to iterators I prefer to use a more generic name.