I read the code review concerning the number of locks in the parameter list:

I can say that for std::lock, the case of 0 and 1 mutex was carefully considered and purposefully rejected.  I considered std::lock to be an algorithm that locked two or more locks without deadlock.  And I did not wish for this algorithm to be accidentally used with 0 or 1 locks as I considered that likely to be a type-o in the code.  Having different syntax for locking a single mutex was a feature as far as I was concerend.

That being said, the author of std::scoped_lock had different desgin ideas and did allow 0 or 1 mutexes.  This point was discussed in committee, and this design was (obviously) approved.  Neither design is completely right or wrong.  And the author of std::scoped_lock showed me a use case of needing the 0 and 1 lock case in a hallway between meetings.  I don’t recall the use-case well enough to reproduce it, but it did seem reasonable.

Nevertheless I wrote this Stack Overflow answer in response:

It argues that the use of lock_guard when dealing with 1 mutex is preferred over scoped_lock (or even unique_lock) to help prevent the accidental type-o of forgetting to provide the mutex.  Compile time errors are always better than run time errors.

Admittedly, I have not put in the same amount of thought regarding try_lock, nor do I have motivating use cases arguing either for or against allowing 0 or 1 arguments.  For try_lock I simply followed the pattern of lock.

So in summary, I’m not recommending adding back the restriction against 0 or 1 locks in the paramter list.  But nor am I recommending you keep that functionality.  I’m recommeding further study on the subject, and an open mind either way going forward.  I stand by my design for lock.  And would strongly object to changing lock to allow 0 or 1 lockables.  But the best answer for the try_lock_xxx algorithms does not have to be the same.

Howard