Fix format_as for non-const begin/end views

[Arghnews]

Fixes issue #3752

base::format does not accept rvalues, using the result of format_as directly means it is passed one. Doesn't matter for ranges with a const begin and end, but since std::ranges::filter_view caches the next value to return, it only has a mutable begin/end iterator.

If we just store the result of format_as in a temporary variable, we can pass it as an lvalue.

Since we use it in

fmt/include/fmt/ranges.h

Lines 485 to 490 in 1dc71f2

	template <typename R, typename FormatContext>
	auto format(R&& range, FormatContext& ctx) const -> decltype(ctx.out()) {
	auto mapper = detail::range_mapper<buffered_context<Char>>();
	auto out = ctx.out();
	auto it = detail::range_begin(range);
	auto end = detail::range_end(range);

And we don't call std::forward anyway, I don't think we're performing any pessimisation by making this change

---

Another way to fix this is by providing a && overload of

fmt/include/fmt/ranges.h

Lines 541 to 545 in 1dc71f2

	template <typename FormatContext>
	auto format(range_type& range, FormatContext& ctx) const
	-> decltype(ctx.out()) {
	return range_formatter_.format(range, ctx);
	}

However other control paths (that pass lvalues) then flow through this, which doesn't seem right, so didn't opt for that method

[vitaut]

Thanks for the PR!

[vitaut]

Can it introduce an extra copy? Can val be a reference?

[Arghnews]

If format_as returns a local variable of type T by value then no extra copy will be made. This was my thought of the predominant use case.

However for a format_as function signature like: const std::string& format_as(T t). Let's say you have a lookup table of std::strings for T, then using auto val always copies, while auto&& val deduces the type of val as a const & so no copy is made.

https://godbolt.org/z/fqMrcY3c3

Thus I think your suggestion of using auto&& is a good one here! Will make the change

[vitaut]

Merged, thanks!