Relax std::move_if_noexcept for std::pair

[François Dumont]

On 12/20/18 11:19 PM, Ville Voutilainen wrote:
> On Thu, 20 Dec 2018 at 23:53, François Dumont <frs.dumont@gmail.com> wrote:
>>>>        This is why I am partially specializing __move_if_noexcept_cond. As
>>>> there doesn't seem to exist any Standard meta function to find out if
>>>> move will take place I resort using std::is_const as in this case for
>>>> sure the compiler won't call the move constructor.
>>> That seems wrong; just because a type is or is not const has nothing
>>> to do whether
>>> it's nothrow_move_constructible.
>> Indeed, I am not changing that.
> Well, if you're not changing that, then I have no idea what is_const
> is doing in your patch. :)
I was not patching nothrow_move_constructible but move_if_noexcept. I 
think I misunderstood your remark.
>>> I don't understand what problem this is solving, and how it's not
>>> introducing new problems.
>>>
>> The problem I am trying to solve is shown by the tests I have adapted.
>> Allow more move semantic in associative container where key are stored
>> as const.
> I'm not sure what you're trying to achieve is doable. The element of
> an associative container is a pair,
> and it has pair's semantics. It's also a pair<const Key, Value>, and
> has those semantics. Those semantics
> are observable.
>
>> But if I make counter_type copy constructor noexcept then I also get the
>> move on the pair.second instance, great. I am just surprise to have to
>> make a copy constructor noexcept to have std::move_if_noexcept work as I
>> expect.
> Well, move construction/assignment via std::move or
> std::move_if_noexcept is not necessarily
> going to invoke just move constructors. Especially not for subobjects,
> like pair's members.
>
>> I think I just need to understand why we need std::move_if_noexcept in
>> unordered containers or even rb_tree. Couldn't we just use std::move ? I
>> don't understand what we are trying to avoid with this noexcept check.
> We are trying to avoid data corruption on exceptions; if you move a
> subobject and have to copy another,
> and then that copy operation throws, you can't reliably move the
> already-moved subobject back. See
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3050.html
> and also
> http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2855.html
>
ok, thanks for those papers, that's much clearer.

François