On Thu, Sep 01, 2022 at 03:07:32PM -0500, Barry Revzin wrote:
> On Thu, Sep 1, 2022, 2:33 PM Mark de Wever <koraq_at_[hidden]> 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 <koraq_at_[hidden]> 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