On Mon, Jul 25, 2022 at 9:14 AM Barry Revzin <barry.revzin_at_[hidden]> 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?)