On 21/12/18 10:05 +0200, Ville Voutilainen wrote:
On Fri, 21 Dec 2018 at 07:43, François Dumont <frs.dumont@gmail.com>
wrote:
>>> 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.
Well, the thing is, move_if_noexcept does just one thing, and that
thing is not customizable.
So your patch partially changes what it means to be
nothrow_move_constructible (from the perspective
of callers of move_if_noexcept), but we shouldn't be changing that,
partially or wholly. The approach is just untenable.
Agreed.
It's not a "problem" that pair<const counter_type, counter_type>
doesn't get moved, because that correctly models what will happen for
real world types that have throwing copy constructors.
You could "fix" it by making counter_type(const counter_type&)
noexcept, just to "fix" some numbers in the tests. But then the tests
would be less realistic.
If you want to verify that moves really do happen when appropriate, I
suggest creating another counter_type (maybe derived from the original
one) and giving it a noexcept copy constructor. Then you can check
that moves happen for *that* type, without making unwanted changes to
the other type (and certainly without making unacceptable hacks to the
move_if_noexcept logic).