On Aug 27, 2025, at 5:56 PM, Ted Lyngmo <ted_at_[hidden]> wrote:
>
> Sure, I can (re)introduce it. I was given some pretty compelling arguments for why it should be removed in the first code review I requested for the implementation:
>> https://codereview.stackexchange.com/questions/297876/freestanding-try-lock-for-try-lock-until/297885#297885
>

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

> The fact that std::lock() and std::try_lock() require two lockables seems like a defect to me.

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:

https://stackoverflow.com/a/60172828/576911
std::lock_guard or std::scoped_lock?
stackoverflow.com

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