Relax std::move_if_noexcept for std::pair

[François Dumont]

On 12/20/18 9:04 AM, Ville Voutilainen wrote:
> On Thu, 20 Dec 2018 at 08:29, François Dumont <frs.dumont@gmail.com> wrote:
>> Hi
>>
>>       I eventually find out what was the problem with the
>> std::move_if_noexcept within associative containers.
>>
>>       The std::pair move default constructor might not move both first
>> and second member. If any is not moveable it will just copy it. And then
> ..as it should..
>
>> the noexcept qualification of the copy constructor will participate in
>> the noexcept qualification of the std::pair move constructor. So
>> std::move_if_noexcept can eventually decide to not use move because a
>> _copy_ constructor not noexcept qualified.
> ..and again, as it should.
>
>>       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.


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

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.

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.

François