Draft: Add support for specifying the separator for range types

[someonewithpc]

This is a draft because I want to get some early feedback on whether this is something we want, and if I'm going about it the right way.

This adds support for the m and n specifiers for ranges and tuples, as described in the cppreference page for std::formatter<pair-or-tuple> and a new , specifier (feedback on the character to use is welcome), such that the separator for elements becomes the string after the specifier.

This partly reverts 16cec4f, but I may be missing the point of that commit, as all tests pass before that commit, including the test introduced in that commit, if the struct formatter<std::pair<K, test_map_value>> specialization is removed. I do not understand the point of that part of the test, as the test doesn't use that formatter. @vitaut Could you explain that?

[vitaut]

The format specs for standard types including ranges are pretty much fixed at this point but you could probably use fmt::join instead of trying to introduce a new specifier. m is quite broken and should probably be deprecated in the standard so I don't think it's worth adding it in {fmt}. So I suggest restricting this PR to implementing the n specifier.

The test in question demonstrates that m is broken for some map element types.

[someonewithpc]

you could probably use fmt::join

That would only do the same thing if we allowed fmt::join(fmt::join(map, map_sep), elem_sep), or fmt::join(map, map_sep, elem_sep, ...). However, in both cases we lose the ability to specify how each element is formatted. Maybe fmt::join(fmt::join(map, map_sep, map_format_string), elem_sep, elem_format_string) or fmt::join(map, { map_sep, map_format_string }, { elem_sep, elem_format_string }) or some new name for a method to do this.

So I suggest restricting this PR to implementing the n specifier.

Can do

[vitaut]

That would only do the same thing if we allowed ...

I don't think we need to overengineer this. There is nothing wrong in handling complex nested cases yourself.

[vitaut]

Closing for now but a PR to implement the n specifier would be welcome.

[someonewithpc]

Closing for now but a PR to implement the n specifier would be welcome.

n only applies to std::pair and std::tuple, and ranges, for which it's already handled, right?

[vitaut]

n only applies to std::pair and std::tuple, and ranges, for which it's already handled, right?

I think so.