Rob Stewart wrote:
From: "Peter Dimov" <pdimov@mmltd.net>
Also, I still think that the bool parameter is better than a "locking" enum, as evidenced by the use case shown in the specification:
scoped_lock lock( m, want_to_lock? locking: non_locking );
I find this an unnecessarily verbose and contrived way to express
scoped_lock lock( m, want_to_lock );
which is the original intent.
I disagree. From the perspective of calling code, using a bool makes things more confusing:
scoped_lock lock1(m, true); scoped_lock lock2(m, false);
From this context, it isn't apparent what "true" and "false" mean. Yes, you can refer to the documentation, but what if you're new to scoped_lock and you forget what it means? Then you'll have to switch contexts, find the docuementation, read about the parameter, and then switch back to see what's really happening in the code.
With the enum, however, the code is self-documenting:
scoped_lock lock1(m, locking); scoped_lock lock2(m, non_locking);
Thus, using the enum eliminates a source of errors and confusion whereas the conditional behavior you mention is still possible, if verbose.
You could have written that about any interface that takes a bool. Perhaps if you take into account some specific properties of scoped_lock you'll be able to argue more convincingly. For example: - a 'locking' lock is actually spelled scoped_lock lock1( m ); - the conditional behavior was actually in Howard's specification as the use case for the constructor, it wasn't merely mentioned by me; - the non-locking case: scoped_lock lock2( m, false ); scoped_lock lock2( m, non_locking ); usually crops up when lock2 is about to be try_locked or timed_locked immediately thereafter. If we include scoped_lock try_mutex_lock( Mutex & m ); that enable Eric Niebler's if( scoped_lock lock2 = try_mutex_lock( m ) ) this will reduce the frequency of the "non-locking locks" considerably.