On Thu, Sep 01, 2022 at 03:07:32PM -0500, Barry Revzin wrote: > On Thu, Sep 1, 2022, 2:33 PM Mark de Wever <[email protected]> wrote: > > > On Thu, Sep 01, 2022 at 02:14:11PM -0500, Barry Revzin wrote: > > > On Thu, Sep 1, 2022, 1:30 PM Mark de Wever <[email protected]> wrote: > > > > For libc++ combining the feature-test macros for these two papers isn't > > > > great: > > > > P2508R1 "Expose std::basic-format-string<charT, Args...>" > > > > P2419R2 "Clarify handling of encodings in localized formatting of > > chrono > > > > types" > > > > > > > > I propose to use two separate macros to resolve the conflicts between > > > > these two papers: > > > > P2508R1 __cpp_lib_format with the value 202207 > > > > P2419R2 __cpp_lib_format_chrono with the value 202207 > > > > > > > But all the chrono formatting is already included in __cpp_lib_format (by > > > way of P1361). If libc++ doesn't support that yet, you can't bump that > > > macro anyway? > > > > I had a look at P1361 before and I just looked again, but it I don't see > > a feature-test macro. (I already had that on a list of notes I have for > > that paper.) > > > > Regards, > > Mark > > > > https://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommendations#__cpp_lib_format > > I don't remember when/where this was discussed, but it's there.
Thanks for the additional information. I still don't like that the chrono part of formatting uses the same feature-test macro, but that ship has sailed years ago. Since that is the status quo I no longer have an objection against the proposed resolution for LWG3750. I wonder, since __cpp_lib_format affects both <format> and <chrono>, should the macro also be defined after including the <chrono> header? And in a similar fashion should the new __cpp_lib_format_ranges be available after including the headers it affects? (Like vector, pair, tuple, etc) Regards, Mark -- SG10 mailing list [email protected] https://lists.isocpp.org/mailman/listinfo.cgi/sg10
