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.

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
   - 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 :-).

Barry

On Mon, Jul 25, 2022 at 10:23 AM Casey Carter via SG10 <
sg10_at_[hidden]> wrote:

> P2286R8, P2419R2, P2508R1, and P2585R1 - all scheduled to be moved in
> today's virtual plenary - want to bump the value of __cpp_lib_format. This
> isn't a great idea, since it means users and implementors cannot
> distinguish the implementation status of these four proposals. I don't
> think this is intentional on LWG's part, I at least don't recall discussion
> of the collision - I think we reviewed these papers far enough apart that
> we managed to forget that we'd already bumped that particular macro.
>
> Should I file an issue to change the feature-test macro status of these
> four proposals, or could we handle this editorially? (Or should I shut up
> and go away?)
> --
> SG10 mailing list
> SG10_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg10
>