Date: Tue, 6 Sep 2022 22:04:45 +0100
I'm afraid I forgot to include this change for the CD and the next WD
(N4917), which now only has the __cpp_lib_format macro, without the
splitting discussed above. However, I believe the feature test macros are
overall editorial in nature, so I would be happy to make the change
immediately now, and nobody needs to file NB comments about it? I gather
also that there's been new discussion, so could you kindly confirm whether
the plan from my previous mail is still acceptable or whether we'd like a
different set of macros now?
All the best,
Thomas
On Wed, 17 Aug 2022 at 12:51, Thomas Köppe <tkoeppe_at_[hidden]> 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.
>>>
>>>> _______________________________________________
>> Lib mailing list
>> Lib_at_[hidden]
>> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/lib
>> Link to this post: http://lists.isocpp.org/lib/2022/07/23266.php
>>
>
(N4917), which now only has the __cpp_lib_format macro, without the
splitting discussed above. However, I believe the feature test macros are
overall editorial in nature, so I would be happy to make the change
immediately now, and nobody needs to file NB comments about it? I gather
also that there's been new discussion, so could you kindly confirm whether
the plan from my previous mail is still acceptable or whether we'd like a
different set of macros now?
All the best,
Thomas
On Wed, 17 Aug 2022 at 12:51, Thomas Köppe <tkoeppe_at_[hidden]> 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.
>>>
>>>> _______________________________________________
>> Lib mailing list
>> Lib_at_[hidden]
>> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/lib
>> Link to this post: http://lists.isocpp.org/lib/2022/07/23266.php
>>
>
Received on 2022-09-06 21:04:57