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_at_[hidden]> wrote:

> 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?)
>