
On Aug 25, 2007, at 2:11 PM, Peter Dimov wrote:
I'll wait for this hypothetical client to appear.
So if we were targeting boost, or even TR2, we would have this luxury. We're not and we don't. We need to get it right the first time. Failing strong consensus of what is "right", we're going to get the current boost::condition. I'm not even positive how to interpret the spec for boost::condition: either mutex-only, or generalized, but definitely not both since it isn't templated.
To try to provide a summary: we have three conditions on the table: (1) unchecked, (2) possibly checked, and (3) checked. Your original design has (3) as default, (1) when the mutex argument is wrapped by unchecked<>. The direction you now seem to be exploring is (1) by default, (3) as an option, which I regard as a regression. I suggest (2) by default, with (3) as an option, but only if there proves to be demand.
Nice summary. I'm very opposed to (2). It says: Here's a constructor and the only difference between it and the other constructor (or other form of the same constructor) is that it adds a bunch of undefined behavior. That just can't be a good thing to put into a standard.
Regardless of what is chosen, I maintain that the three conditions must syntactically have the same interface, that is, it must be possible to pass a mutex even to (1). It would be painful to switch between them if they do not.
I've actually been doing this switching a lot recently in my prototype and associated test code. It isn't that painful. But I agree it would be nice to not have to do it at all. If we only manage to standardize (1), then justifying a constructor that looks different but has no difference in behavior is hard to justify. If we manage to standardize both (1) and (3), then it becomes much easier to justify such a constructor. I'm strictly looking at this from the client's point of view. I'm the client. I know what I want, and I want to be able to pick something and know what it does. I don't want to be stuck with something that maybe does something, and maybe not. It's like buying something with absolutely no warranty. -Howard