C++ Logo


Advanced search

Re: Feature-test macro collision

From: Casey Carter <Casey_at_[hidden]>
Date: Mon, 25 Jul 2022 09:52:19 -0700
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
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?)

Received on 2022-07-25 16:52:33