Date: Thu, 1 Sep 2022 20:30:26 +0200
Sorry for the late reply, but I wasn't subscribed to this mailing list
and I wasn't aware there were proposed changes for fix the feature-test
macro conflicts introduced during the last plenary.
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"
P2508R1 is included in libc++15 which should ship this month. (The only
part I haven't implemented for that paper is the feature-test macro.)
I have started to work on the chrono formatters in libc++ but it will
take some time before it will be done. Especially since libc++ still
misses parts of C++20 chono: timezones, leapseconds, and some clocks.
So it will take some time before I have a look at P2419R2.
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
Combining the two formatting ranges papers in __cpp_lib_format_ranges
sounds good to me.
Regards,
Mark
On Wed, 17 Aug 2022 12:51:02 +0100, Thomas Köppe wrote:
> Thanks, everyone! So I will proceed as follows:
>
> - __cpp_lib_format will be bumped, and is to refer only to P2419R2
> ("Clarify handling of encodings in localized formatting of chrono types")
> and P2508R1 ("Expose std::basic-format-string<charT, Args...>").
> - A new macro __cpp_lib_format_ranges will be added to refer to P2286R8
> ("Formatting Ranges") and P2585R1 ("Improve container default formatting"),
> and those papers will NOT be tracked by __cpp_lib_format anymore (as a
> material change to the approved content).
>
> Is that acceptable?
>
> The change will be applied after all the motions.
>
> Thank you!
>
> Thomas
>
> On Tue, 26 Jul 2022 at 23:42, Casey Carter via Lib <lib_at_[hidden]>
> wrote:
>
> > Related: P1224R4 flat_set is missing a feature-test macro. Could we add
> > __cpp_lib_flat_set for it?
> >
> > On Mon, Jul 25, 2022 at 6:29 PM Casey Carter <Casey_at_[hidden]> wrote:
> >
> >> On Mon, Jul 25, 2022 at 4:59 PM Victor Zverovich <
> >> victor.zverovich_at_[hidden]> wrote:
> >>
> >>> 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.
> >>>
> >>
> >> For the record, I'm willing to accept Victor's expert assertion that
> >> these are both small enough that there's no reason to support separate
> >> implementation and that a single macro bump is good.
and I wasn't aware there were proposed changes for fix the feature-test
macro conflicts introduced during the last plenary.
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"
P2508R1 is included in libc++15 which should ship this month. (The only
part I haven't implemented for that paper is the feature-test macro.)
I have started to work on the chrono formatters in libc++ but it will
take some time before it will be done. Especially since libc++ still
misses parts of C++20 chono: timezones, leapseconds, and some clocks.
So it will take some time before I have a look at P2419R2.
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
Combining the two formatting ranges papers in __cpp_lib_format_ranges
sounds good to me.
Regards,
Mark
On Wed, 17 Aug 2022 12:51:02 +0100, Thomas Köppe wrote:
> Thanks, everyone! So I will proceed as follows:
>
> - __cpp_lib_format will be bumped, and is to refer only to P2419R2
> ("Clarify handling of encodings in localized formatting of chrono types")
> and P2508R1 ("Expose std::basic-format-string<charT, Args...>").
> - A new macro __cpp_lib_format_ranges will be added to refer to P2286R8
> ("Formatting Ranges") and P2585R1 ("Improve container default formatting"),
> and those papers will NOT be tracked by __cpp_lib_format anymore (as a
> material change to the approved content).
>
> Is that acceptable?
>
> The change will be applied after all the motions.
>
> Thank you!
>
> Thomas
>
> On Tue, 26 Jul 2022 at 23:42, Casey Carter via Lib <lib_at_[hidden]>
> wrote:
>
> > Related: P1224R4 flat_set is missing a feature-test macro. Could we add
> > __cpp_lib_flat_set for it?
> >
> > On Mon, Jul 25, 2022 at 6:29 PM Casey Carter <Casey_at_[hidden]> wrote:
> >
> >> On Mon, Jul 25, 2022 at 4:59 PM Victor Zverovich <
> >> victor.zverovich_at_[hidden]> wrote:
> >>
> >>> 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.
> >>>
> >>
> >> For the record, I'm willing to accept Victor's expert assertion that
> >> these are both small enough that there's no reason to support separate
> >> implementation and that a single macro bump is good.
Received on 2022-09-01 18:30:31