2008/6/23 David Abrahams <dave@boostpro.com>:
I have a hunch that it would be really easy to add support for move-only types, though. Do you see any specific obstacles?
I haven't really thought about it much. Since there are already other solutions, I thought the easiest thing might be to use one of them. But I haven't looked at them in detail yet.
I'm not going to work on a new way of making the container itself movable when its elements aren't.
Hm. I don't know what you mean by "a new way," but for most containers, movability of the element is irrelevant. boost::array and tuples are the only exceptions I can think of. Could you clarify?
I believe that if the container uses the current Adobe move implementation to make itself movable, then it will only be movable when it is also copyable, which it won't be if the elements are move-only. But we'd probably want the container to be movable in this case, which would require something extra (the 'new way' I was referring to). If it's easy to add support for move-only types, then maybe this wouldn't be too much to do.
I don't know whether you consider this relevant, but I think that Boost ought to adopt something like Adobe's move-aware standard container collection, just to avoid layering issues (something in boost needs a move-aware container, so it uses ASL, which in turn uses boost).
I think that's pretty much what Ion is proposing for the Interprocess containers. Daniel