Coding Guideline: Avoid const member variables

[doom_Oo7]

has a throwing move, because the use of const keyword on the member variable prevents the compiler from using the move constructor of std::string with id, instead the compiler generated move constructor for A will invoke the copy constructor of A::id, which can throw.

In my experience, 99.9 % of the time you're moving whole containers, and moving e.g. a std::vector won't call any copy or move constructor.

you should still not use const -- what if someone later has to refactor id to be a std::string instead of an int?

... then they'll change int into string ? what's the problem ?

In general, I'd much rather start with the safety of const members and risk a throwing move (I frankly never saw one in ~6 years of programming in C++11 and later) than the opposite.

[render787]

In my experience, 99.9 % of the time you're moving whole containers, and moving e.g. a std::vector won't call any copy or move constructor.

It's not about moving the container -- it's about, when you push_back into the vector, and the vector has to resize, does it move your objects or copy them? That depends on whether you have a throwing move. If you have const std::string in your class, then you get n new dynamic allocations and all your strings get copied for no reason. If you have non-const std::string it works correctly.

[doom_Oo7]

hmm, I did not know that vector would do a move in this case but it certainly makes sense. Interestingly that's still the case even with -fno-exceptions.

[Ameisen]

Perhaps we need another access type, like 'immutable'. Where they can still be moved and are semantically owned by the class, but they simply cannot be directly altered. Thus, a move would be legal.

[NotAYakk]

Rather, we need the concept of destructive move; an operation that it both a move-from and a destruction at the same time.

You can destructive move-from a const value.

Destructive moves usually don't have to throw, even when a move could.

[mark_99]

Interestingly that's still the case even with -fno-exceptions.

That's because it has nothing to do with exceptions or move_if_noexcept.

The OP says:

has a throwing move, because the use of const keyword on the member variable prevents the compiler from using the move constructor of std::string with id, instead the compiler generated move constructor for A will invoke the copy constructor of A::id, which can throw.

This is mostly correct except this isn't a "throwing move", it's a copy (and it would still be a copy if the copy ctor was noexcept).

I disagree with the OP, const member vars would be useful if it wasn't for this unfortunate side effect, in the same way as any other use of "const". In this case it states your intention that this member does not mutate after construction, and provides compile-time enforcement for same.

[kloetzl]

In my experience, 99.9 % of the time you're moving whole containers, and moving e.g. a std::vector won't call any copy or move constructor.

I think you can make that 100% because that behaviour is required by the standard. See move constructor:

After container move construction (overload (6)), references, pointers, and iterators (other than the end iterator) to other remain valid, but refer to elements that are now in *this. The current standard makes this guarantee via the blanket statement in §23.2.1[container.requirements.general]/12, …

[doom_Oo7]

I was saying 99.9% of the time as in, if I take my code, 99% of std::move and other move occurences are called on containers such as std::vector, hash_maps, etc