You’re welcome; it’s my pleasure!

I don’t claim to understand this stuff as well as the posters here, but it feels like a big disappointment that the move operations of the standard containers are not required to be no-throw. Doesn’t that make it impossible to write our own non-throwing move-enabled classes in terms of the standard containers (without adding a level of indirection)?

The circumstances where you can’t actually write such a non-throwing move-enabled class without indirection are actually considerably narrower than that. But that’s not the interesting part. The interesting part is that it usually doesn’t matter whether a move constructor throws. I’m long overdue for writing an article explaining the issues as they have finally shaken out, including the outcome for N2983. I promise to get something out in the next week or so.

If I understand the comments correctly, the reason for not requiring no-throw is that we may need to allocate memory in order to put the moved-from object back into a usable state.

Not really. Try to hang in there for a followup article where I can explain this.

But (again I may be misunderstanding this) the standard isn’t offering us any guarantees about the state of a moved-from container anyway.

The standard guarantees that the object still functions as a well-behaved instance of the type, but beyond that, no, you don’t know anything about its state.

For example we can’t (portably) call push_back on a moved-from std::list and expect it to end up with size() == 1. If all we can reliably do with a moved-from container is to assign to it or destroy it,

That overstates the case. You can reliably do all the same things with a moved-from container that you can do with a container someone has passed to a function by reference, where (unless you’ve imposed requirements in documentation) you don’t know anything about the state of that container.

and a move constructor which does this can be implemented without any allocation (yes?), wouldn’t it have made sense to require a non-throwing implentation?

Frankly I need to go back and review the state of the [latest draft standard](http://open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3090.pdf) before I can responsibly accept your premises about `std::list`.

(Apologies for commenting so long after the event; a year ago I’d only just learnt what a copy constructor was, never mind a move constructor…)

Comments are always welcome; thanks for being part of the community!

I don’t claim to understand this stuff as well as the posters here, but it feels like a big disappointment that the move operations of the standard containers are not required to be no-throw. Doesn’t that make it impossible to write our own non-throwing move-enabled classes in terms of the standard containers (without adding a level of indirection)?

If I understand the comments correctly, the reason for not requiring no-throw is that we may need to allocate memory in order to put the moved-from object back into a usable state. But (again I may be misunderstanding this) the standard isn’t offering us any guarantees about the state of a moved-from container anyway. For example we can’t (portably) call push_back on a moved-from std::list and expect it to end up with size() == 1. If all we can reliably do with a moved-from container is to assign to it or destroy it, and a move constructor which does this can be implemented without any allocation (yes?), wouldn’t it have made sense to require a non-throwing implentation?

(Apologies for commenting so long after the event; a year ago I’d only just learnt what a copy constructor was, never mind a move constructor…)

But what about move assignment?

After some further pondering I came to the following conclusion (using proposed type traits from N2983):

 
  template<typename T>
  struct has_potentially_throwing_move_ctor
  : std::integral_constant<bool,(
    has_move_constructor<T>::value &&
    !nothrow_move_constructible<T>::value
  )> {};
 
  template<typename T>
  struct has_potentially_throwing_move_assign
  : std::integral_constant<bool,(
    has_move_assign<T>::value &&
    !nothrow_move_assignable<T>::value
  )> {};
 
   template <class T>
  typename conditional<
       (   has_potentially_throwing_move_ctor<T>
        && has_copy_constructor<T> )
    || (   has_potentially_throwing_move_assign<T>
        && has_copy_assignment<T> ) ,
    T const&,
    T&&
  >::type move_if_noexcept(T& x) { return std::move(x); }
 

The function doesn’t exactly behave like its name suggests — it does return T&& in some cases even if a move operation potentially throws — so maybe there’s a better name for it. But currently, its behaviour looks like a good compromise to me.

I’d love some feedback.

template <class T>
 typename conditional<
        potentially_throwing_construction<T,T&&>::value
     || potentially_throwing_assignment<T,T&&>::value
     T const&,
     T&&,
 >::type
 move_if_noexcept(T& x)
 {
     return std::move(x);
 }
 

I think that’s exactly what move_if_noexcept should do. But I’m not sure if it’s possible to get something equivalent with the traits that are defined in N3000.

template <class T>
 typename conditional<
     !nothrow_move_constructible<T>::value
     && has_copy_constructor<T>::value,
     T const&,
     T&&
 >::type
 move_if_noexcept(T& x)
 {
     return std::move(x);
 }
 

Let me rewrite the return type without double negative so it’s less confusing:

 typename conditional<
     nothrow_move_constructible<T>::value
     || !has_copy_constructor<T>::value,
     T&&
     T const&,
 >::type
 

So, appearently move_if_noexcept also returns an rvalue reference for move-only types regardless of whether the move constructor throws or not. If the function’s name is any indication of a contract this looks like a breach of contract to me.

In addition, there’s a chance that some user wants to use move_if_noexcept for move assignments as well, not just move constructions. But the conditional just checks for a throwing move construction. Now, I realize that for most move-enabled types nothrow_move_constructible<T> will be equal to nothrow_move_assignable<T> but it is also possibe to write a class where only one of these operations throws and the other one doesn’t. Consider a type with a non-throwing move ctor but a throwing move assignment. This definition of move_if_noexcept will allow a throwing move assignment in this case.

What about this one?

template <class T>
 typename conditional<
     nothrow_move_constructible<T>::value
     && nothrow_move_assignable<T>::value,
     T&&
     T const&,
 >::type
 move_if_noexcept(T& x)
 {
     return std::move(x);
 }
 

This implementation honors its contract. It only returns an rvalue reference if both operations (move construction and move assignment) don’t throw. In rare cases it’ll decrease performance due to being a little more conservative. But I think that’s acceptable. It’ll also lead to some code being rejected. There just isn’t anything you can do about move-only types with a throwing move, is there?

Any news ? I’m really eager to see that one.

It’s odd because in all article on rvalue references I saw (including yours so far ), a big part is always assign to move semantic and very little on perfect forwarding. And yet, I have the feeling that perfect forwarding will be as much important in Ox as move semantic.

I’m sure there are several floating around out there. I’m less sure that I would agree with any of them

I thought that I ‘feel’ what it is but when I once thought of the definition it all becomes vague. I can think of at least three:

1. Using copy/move constructor, copy/move assignment and operator==/!= properly.
2. Objects (of user defined types) represent values that can be copied, and compared.
3. We pass arguments to functions and return from functions by value.

Those are all in the right ballpark as far as I’m concerned.

Therefore, a number of questions arise regarding the name ‘Value Semantics’:

1. Is it applicable only to languages of C family (C++, D, Java, C#)?
2. Is it correct that objects in Java support value semantics, because we have: copy constructor and methods clone and equals, which provide copying and comparison?

I was wondering if I could request an article on the definition of Value Semantics.

You can certainly request, and we do intend to fulfill all of our promises, eventually Unfortunately, I haven’t thought all the issues through quite enough yet to write that article today. However, I can address your two questions above:

1. Actually, of the above only C++ really supports what I mean by value semantics. Here’s a crucial test: can you write a mutable Matrix type that has the usual copy, assignment, etc. semantics? Of crucial importance is that in this example,

   1
   2
   

   Matrix x = y;
   y[0][0] = 3.14;

   the value of x is not modified by line 2.

2. For me, syntax matters. Copying an object via y = x.clone() and especially comparing objects with x.equals(y) don’t count

1. Using copy/move constructor, copy/move assignment and operator==/!= properly.
2. Objects (of user defined types) represent values that can be copied, and compared.
3. We pass arguments to functions and return from functions by value.

Therefore, a number of questions arise regarding the name ‘Value Semantics’:

1. Is it applicable only to languages of C family (C++, D, Java, C#)?
2. Is it correct that objects in Java support value semantics, because we have: copy constructor and methods clone and equals, which provide copying and comparison?

I was wondering if I could request an article on the definition of Value Semantics.

Regards, &rzej