Peter Dimov wrote:
Yuval Ronen:
Peter Dimov wrote:
I meant "helps people avoid accidental mistakes at the time they're writing the code". The function encourages correct use by asking for a lock, implying that the mutex needs to be locked first. Hinting the user to lock a mutex by accepting a lock is getting too psychological for my taste. If it was enforced by the compiler, then maybe, but since the compiler can't...
The hint isn't particularly subtle. You have to pass a lock, and this _is_ enforced by the compiler. The rest of the enforcement (that the lock 'owns' the correct mutex) is necessarily postponed to run time; we simply can't do better than that.
I'm really not sure how you propose to achieve the same level of encouraging and enforcing correct use with a wait function that doesn't take a lock argument,
I'm saying that there's no need to achieve the same level of enforcing. Checking in runtime is enough, IMO. Just as we don't enforce locking before accessing a shared resource (because we can't), there's no need to go over hoops (see my next paragraph) to enforce more than at runtime.
and I'm also unsure what specific problems with requiring a lock argument are you trying to solve.
I find the lock argument cumbersome. In a way it's redundant to passing the mutex, and for no good reason - just for hinting, subtle or no subtle. Where else in C++ a user is hinted in such a way? It's without precedent, and plain weird in my eyes. And if we add to this the fact that it's only a partial compile-time check, then it makes things even weirder. The user, for example, can confuse and think that he is fully covered by the compile-time check, and continue with his guards down, passing it a non-owning unique_lock. If we can't do a complete job, it's better to not do it at all, at least this way our users are forced to be aware of what's happening.