Supporting nested format specs for ranges.

[brevzin]

Basic support for nested formatters for ranges from P2286. This does not add any top-level range format specifiers (pad/align/width/empty/delimiter), but does add the placeholder colon for them for the future.

[brevzin]

I more or less copied this from join, but I feel like there's probably a more direct way of getting the right formatter_type?

[vitaut]

Not if we want to support implicit conversions. I suggest moving it to a new trait in detail and using in both places.

[vitaut]

Thanks for the PR! Overall looks good but please address the inline comments.

[vitaut]

I think value_type is more descriptive because this gives the range value type. The fact that cvref is removed is less important.

[brevzin]

It doesn't give the value_type though, it gives you the range's reference - with cvref stripped. A lot of the time, that is the value_type, but not always. For example: for vector<bool> the value_type is bool but this gives you vector<bool>::reference (which is what we would actually use to format). Or zipping two vector<int>s has a value_type of pair<int, int> but this gives you pair<int&, int&>.

I wanted to change it mainly because calling it value_type is misleading - we never use the range's value_type for anything.

[vitaut]

OK but could you clarify this in the comment then?

[brevzin]

Sure.

[brevzin]

Uh, I'm failing CI because of... throwing exceptions? I don't understand.

[vitaut]

Uh, I'm failing CI because of... throwing exceptions? I don't understand.

Not sure what you are referring to but the error is

'parse': is not a member of 'fmt::v8::detail::fallback_formatter<int [3][2],Char,void>

[brevzin]

Uh, I'm failing CI because of... throwing exceptions? I don't understand.

Not sure what you are referring to but the error is

'parse': is not a member of 'fmt::v8::detail::fallback_formatter<int [3][2],Char,void>

@phprus pointed out that it was because I was doing throw format_error(...) instead of FMT_THROW(format_error(...)). Unrelated to the int[3][2] problem -- the exceptions one was causing half the CIs to fail.

This one I don't understand. Only fails on Windows too?

[vitaut]

Looks like on MSVC the formatter specialization for int (&)[3][2] somehow becomes disabled with these changes (has_formatter returns false).

[brevzin]

Looks like on MSVC the formatter specialization for int (&)[3][2] somehow becomes disabled with these changes (has_formatter returns false).

This seems like an MSVC bug. Here's an example:

#include <utility>

namespace fmt2 {
    template <typename T, size_t N>
    auto range_begin(T(&)[N]) -> T*;

    template <typename R>
    using iterator_t = decltype(range_begin(std::declval<R&>()));

    template <typename R>
    using reference_t = decltype(*std::declval<iterator_t<R>&>());
}

using R = int[3][2];

static_assert(
    std::is_same_v<
        fmt2::iterator_t<R>, int(*)[2]
        >,
    "!"
);

static_assert(
    std::is_same_v<
        fmt2::reference_t<R>, int(&)[2]
        >,
    "!"
);

The reference type of int[3][2] should be int(&)[2]. But MSVC v19.16 thinks it's int(*&&)[2]. Which is not a range. It's like they totally ignore the *. MSVC v19.21 still miscompiles, MSVC v19.22 gets this right.

If it's just arrays, I guess could add special handling for arrays for MSVC? This is probably the same bug that you were already working around in this space:

// Workaround a bug in MSVC 2019 and earlier.

[brevzin]

I got an email about checks failing, but it looks like all the checks passed? I don't even know.

[vitaut]

Merged, thanks!

[vitaut]

@brevzin could you by any chance add a section documenting this new feature (similarly to https://github.com/fmtlib/fmt/blob/master/doc/syntax.rst#chrono-format-specifications)?