Created on 2025-03-06.00:00:00 last changed 3 weeks ago
[ 2026-05-19 Status changed: New → NAD. ]
Defining a range like that is is a self-inflicted wound, analogous to deleting a move constructor so a type can be copied but not moved. Don't do that. If you really need to, then you can just define your own `formatter` specialization for your range, which could still use `range_formatter` internally to do the real work. Or you can format `std::span(std::as_const(r))` or `std::views::all(std::as_const(r))` or various other ways to adapt it into a formattable range.
[ 2025-10-21; Reflector poll. ]
Set priority to 2 after reflector poll.
The majority voted NAD, because the range shown in the issue is nonsensical. But enough people voted P2 that we should not close it without more discussion.
The standard does not explicitly prohibit ranges that are only const-iterable, i.e. a range with
const begin() and deleted or invalid non-const begin().
Unfortunately, those ranges cannot be formatted because the R in
formatter<R> is always without the const-qualifier,
which makes it never satisfy the range concept
(demo):
#include <print>
#include <ranges>
struct R {
int* begin() = delete;
int* end() = delete;
const int* begin() const;
const int* end() const;
};
int main() {
const R r;
static_assert(std::ranges::contiguous_range<decltype(r)>);
for (auto&& elem : r)
std::print("{} ", elem); // ok
std::ranges::for_each(
r, [](auto&& elem) { std::print("{} ", elem); }
); // ok
std::print("{}", r); // not ok
}
Although such type might be relatively rare, it does reflect an inconsistency in the general usage of formatting ranges, which do not support all valid ranges.
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2026-05-19 21:25:09 | admin | set | messages: + msg16308 |
| 2026-05-19 21:25:09 | admin | set | status: new -> nad |
| 2025-10-21 14:07:47 | admin | set | messages: + msg15312 |
| 2025-03-06 00:00:00 | admin | create | |