Christopher Currie wrote:
Michael Glassford wrote:
I believe there was (nearly?) consensus that we want to make locks movable at some point. My conclusion was that at that point this syntax becomes possible, too. I think Peter said or implied much the same thing, maybe before I did.
I'm just going to be the voice of dissent here, again, and argue that the scoped_locks, at least, should not be moveable, otherwise they're not very scoped. The scoped lock serves a specific purpose in ensuring that the mutex doesn't remain locked outside of block scope, just like scoped_ptr ensures that a heap object has a specific lifetime.
If there's enough hew and cry for a movable lock, then we should create a new class for it. That said, most of the arguments I could find on the list archive for it are to support syntax changes in initializing a scoped lock.
Did you see http://aspn.activestate.com/ASPN/Mail/Message/boost/1207226, and especially http://aspn.activestate.com/ASPN/Mail/Message/1209126?
I also saw an argument for storing locks in containers, which I can't quite fathom the need for, but I welcome the use cases.
As a compromise, we could create lock_transfer<> objects that wouldn't lock a mutex, but would allow initialization syntax in places where the language makes it difficult (this is just a quick sketch, there may be errors):
[snip code example] Mike