Adding __cpp_lib_format_ranges for P2286 and P2585 sounds like a good idea.

P2508 and P2419 are minor (from the implementation perspective) changes so I think just bumping the __cpp_lib_format macro is fine.

Cheers,
Victor

On Mon, Jul 25, 2022 at 9:52 AM Casey Carter <Casey@carter.net> wrote:
On Mon, Jul 25, 2022 at 9:14 AM Barry Revzin <barry.revzin@gmail.com> wrote:
Two of these are very tightly coupled (P2286 and P2585 both deal with formatting ranges) and I would expect them to be implemented together (since otherwise you'd implement P2286 then rewrite a bunch of things). P2508 is just exposing a type that implementations already use, so is trivial, and would be valuable to get out faster. I don't know what P2419 entails since I don't know anything about Unicode.

Apologies for not including titles with the paper numbers. The four proposals in question are:
P2419R2 "Clarify handling of encodings in localized formatting of chrono types"
P2508R1 "Expose std::basic-format-string<charT, Args...>"
P2286R8 "Formatting Ranges"
P2585R1 "Improve container default formatting"
 
It would make sense to me to either:
  • P2286 and P2585 instead use __cpp_lib_format_ranges or something (even though the former also adds formatting for pair/tuple), or
 I like this / agree there's no need for separate implementation.
  • Put a different value for those two? I mean, they don't HAVE to use 202207 right? Could we just use 202208 for those and like 202206 for P2508 (the easy one)?
Pretty sure P2508 is going to be implemented first :-). 

 I could see either:
* P2508 is 202207 and P2419 is 202208, or
* P2508 is 202207 and P2419 gets a new macro (__cpp_lib_format_transcoding?)