[libcxx-dev] Sequence container swap noexcept specifiers not-to-spec

[Tim Song via libcxx-dev]

My interpretation is

- the _LIBCPP_STD_VER >= 14 unconditional noexcept is a permissible
strengthening relative to the standard's requirement. The conditional
noexcept in the standard is a Lakos rule relic because of the UB in
https://timsong-cpp.github.io/cppwp/container.requirements.general#9.sentence-4.
- the _LIBCPP_STD_VER < 14 conditional noexcept is an attempt to
support allocators that throw when swapped. Those allocators were
banned by LWG2016.

So everything is OK as is, but there may be a case for treating
LWG2016 as a DR and making this function unconditionally noexcept
across all standard versions.

On Thu, Mar 4, 2021 at 11:24 AM Christopher Di Bella <cjdb.ns at gmail.com> wrote:
>
> Ah, I was looking for a big "Resolved" status and missed that.
>
> So IIUC you're saying the conditional noexcept specifier is a relic required by the Lakos rule, but is always true thanks to LWG2016, and an allocator that throws in its swap in libc++ calls std::terminate, which is our resolution to UB, and so everything is already A-OK.
>
> On Thu, 4 Mar 2021, 09:16 Tim Song, <t.canens.cpp at gmail.com> wrote:
>>
>> On Thu, Mar 4, 2021 at 11:14 AM Christopher Di Bella <cjdb.ns at gmail.com> wrote:
>> >
>> >
>> >
>> > On Thu, 4 Mar 2021, 09:03 Tim Song, <t.canens.cpp at gmail.com> wrote:
>> >>
>> >> I don't think this is an oversight. The conditional noexcept on swap
>> >> in the standard is entirely due to the Lakos rule (swapping containers
>> >> with non-propagating unequal allocators is undefined), so the
>> >> unconditional noexcept is a permissible strengthening. The
>> >> __is_nothrow_swappable check pre-17 is presumably to support
>> >> allocators with throwing swaps, which were banned by LWG2016.
>> >>
>> >> If a change is desirable, I would suggest treating LWG2016 as a DR and
>> >> using unconditional noexcept across the board.
>> >
>> >
>> > I see LWG2016 is P2 and hasn't been looked at since 2017. What would be necessary to get LWG to review this again?
>> >
>>
>> It's in C++17 already?