Why move is not implicitly noexcept?

[Öö Tiib]

I can hardly imagine any reasons to throw from destructor, move constructor
or move assignment.

The destructor is implicitly noexcept unless there are bases or members
that have noexcept(false) destructors.

Does anyone know why move constructor and move assignment are implicitly
noexcept(false)? By default (e.g. = default) these are also noexcept(true)
when possible like the destructor is.

[Daniel]

On Monday, November 27, 2017 at 11:04:00 AM UTC-5, Öö Tiib wrote:
> I can hardly imagine any reasons to throw from ... move constructor
> or move assignment.
>
One reason, if move must replace an allocator, and propagate_on_container_move_assignment::value is false, the implementation may want to perform a copy, then copy can throw.

Daniel

[Alf P. Steinbach]

Today move semantics is a bit more, but originally it was an
optimization of copying.

As I recall, for that purpose some felt it was important that move
operations could be generated automatically by the compiler, wholly or
partially in terms of old possibly-throwing copy operations.

With such partially copy-based move operations, one hoped to get
significant speedups for legacy code just by recompiling, and over time
more of that the more old pure copy semantics in such code was
complemented with user defined move operations.

Regardless of whether my recollection of the rationale is correct,
having possibly throwing move operations was considered sufficiently
important to introduce a possible UB in std::vector reallocation, and to
generally just complicate things.

I think that decision was wrong: let's design this car partially as a
tractor so that it will work in some fashion also out in the fields, not
just on the road. Huh? What?

My 2c.


Cheers!,

- Alf

[Öö Tiib]

Thanks. Yes, C++17 made move assignments of the containers
that have allocator with 'propagate_on_container_move_assignment'
or 'is_always_equal' trait noexcept(true). That means 99.9% of
containers. Before C++17 all the move assignments of all containers
were noexcept(false).

We technically talk about unusual container whose owned resources
can not be transferred because of its odd allocator.
Why not to make such container simply not move-assignable?

[Öö Tiib]

On Tuesday, 28 November 2017 05:43:40 UTC+2, Alf P. Steinbach wrote:
> On 11/27/2017 5:03 PM, Öö Tiib wrote:
> > I can hardly imagine any reasons to throw from destructor, move constructor
> > or move assignment.
> >
> > The destructor is implicitly noexcept unless there are bases or members
> > that have noexcept(false) destructors.
> >
> > Does anyone know why move constructor and move assignment are implicitly
> > noexcept(false)? By default (e.g. = default) these are also noexcept(true)
> > when possible like the destructor is.
> >
>
> Today move semantics is a bit more, but originally it was an
> optimization of copying.
>
> As I recall, for that purpose some felt it was important that move
> operations could be generated automatically by the compiler, wholly or
> partially in terms of old possibly-throwing copy operations.
>
> With such partially copy-based move operations, one hoped to get
> significant speedups for legacy code just by recompiling, and over time
> more of that the more old pure copy semantics in such code was
> complemented with user defined move operations.

I have had same impression. The programmers do not typically care if
the underlying resources of throw-away objects are transferred or copied.
It is quite inconvenient to make some higher level logic dependent on
such low level details so it was quite bad legacy hack that did break
because of recompiling with C++11.

However we must care if something can throw exceptions or cannot and
(if possible) even what these exceptions are. ;)

> Regardless of whether my recollection of the rationale is correct,
> having possibly throwing move operations was considered sufficiently
> important to introduce a possible UB in std::vector reallocation, and to
> generally just complicate things.

Most robust would be to demand that move constructors and move assignments
simply may not throw. If author can't ensure that then '= delete' it and
done. The cloud of complications (like 'std::is_nothrow_move_assignable')
that no novice will ever learn to use correctly would vanish.

> I think that decision was wrong: let's design this car partially as a
> tractor so that it will work in some fashion also out in the fields, not
> just on the road. Huh? What?

Yes, and if they wanted actually ATV then why they did mount both the
spoiler and the snowplough to it? However I was not even dreaming of
anything charming. I was merely wondering why the move operations are
implicitly so inconveniently noexcept(false) while it is rather unusual
that these throw.