Re: Relax std::move_if_noexcept for std::pair

[Ville Voutilainen <ville.voutilainen@gmail.com>]

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 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