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 <[email protected]> wrote: > On Mon, Jul 25, 2022 at 9:14 AM Barry Revzin <[email protected]> > 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?) >
-- SG10 mailing list [email protected] https://lists.isocpp.org/mailman/listinfo.cgi/sg10
