In D140913#4119271, @ldionne wrote:

In D140913#4078953, @tcanens wrote:

Per https://lists.isocpp.org/lib/2018/11/9316.php allocate_shared_for_overwrite should not call allocator_traits::destroy, which I think this implementation does?

Ugh, it shouldn't be destroyed at all? I hadn't read it that way.

Per https://lists.isocpp.org/lib/2018/11/9316.php allocate_shared_for_overwrite should not call allocator_traits::destroy, which I think this implementation does?

http://eel.is/c++draft/algorithms.requirements#13

In D107098#2916919, @ldionne wrote:

In D107098#2915589, @tcanens wrote:

Just a quick note: when P2281R1 talks about perfect forwarding call wrappers, it really means perfect forwarding call wrappers exactly as specified in the standard, that is:

A perfect forwarding call wrapper is an argument forwarding call wrapper that forwards its state entities to the underlying call expression. This forwarding step delivers a state entity of type T as cv T& when the call is performed on an lvalue of the call wrapper type and as cv T&& otherwise, where cv represents the cv-qualifiers of the call wrapper and where cv shall be neither volatile nor const volatile.

In particular, invoking an rvalue wrapper must deliver the state entity as an xvalue and cannot fall back to const lvalue the way __perfect_forward does (without deducing this, I believe that this requires additional deleted operator() overloads). This is particularly significant for split - see the examples in the paper.

Thanks a lot for the heads up. However, I'm not entirely sure I understand where the issue is, because what I'm seeing for __perfect_forward is this (leaving aside noexcept and -> decltype):

template<class... _Args>
constexpr auto operator()(_Args&&... __args) &&
{return _Op::__call(std::get<_Idxs>(std::move(__bound_))..., std::forward<_Args>(__args)...);}

Since we call std::get on std::move(tuple), I think we end up passing rvalue references to __call, don't we? Or did you mean something else?

Just a quick note: when P2281R1 talks about perfect forwarding call wrappers, it really means perfect forwarding call wrappers exactly as specified in the standard, that is:

In D102135#2837041, @ldionne wrote:

At first, I didn't understand the purpose of this type. Now I think I do - it's to turn something that is copy-constructible (but maybe not copy assignable) into something that is both copy-constructible and copy-assignable. It does that by using an optional and basically doing destroy-then-copy-construct in the assignment operator.

In D103478#2794869, @Quuxplusone wrote:

I was looking at how to implement compare_three_way and found out that it needs to be present in both <compare> and <functional> according to the standard draft ( <function> synopsis, <compare> synopsis).

Sounds like someone should file an LWG issue. I'm not aware of any other library facilities that are listed multiple times in different places in the Standard. This might be a cut-and-paste error.

I think something like remove or rotate (and more generally algorithms that require the use of the new iter_move and iter_swap customization points) might be a more interesting exercise.

rejected both nullptr_t ([cmp.categories]/p3 notes that "nullptr_t meets this requirement" at the end of the paragraph)

In D100255#2714675, @cjdb wrote:

In D100255#2713772, @tcanens wrote:

The array-of-incomplete-element case is IFNDR. I think we really want that case to be a SFINAE-unfriendly hard error, since it's a recipe for disaster (ODR violations).

Won't the deleted overloads take care of that?

The array-of-incomplete-element case is IFNDR. I think we really want that case to be a SFINAE-unfriendly hard error, since it's a recipe for disaster (ODR violations).

The exact expression in an atomic constraint is not observable so you can certainly substitute something else if that is preferable for whatever reason.

For append, we can always use the optimized approach, because if an iterator operation throws, we just restore the null terminator and we're back where we started, no problem.