On Wed, Aug 27, 2025 at 4:42 PM Ted Lyngmo via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> I've made a first draft for the proposal [...]
> which I've attached. This is the first time I've even come this far with
> an idea and I would be very grateful for feedback.
>

> Returns: true if all locks were obtained, otherwise false.

Why not return the integer index of the culprit that failed to lock, as
`std::try_lock()` does? I have no particular use-case in mind, but the
general philosophy of the STL is that if we have computed some useful
information and we have a convenient way to return it, we shouldn't throw
it away.
The nightmare scenario here is that I use your new thing to write some
C++XY code like
    if (std::try_lock_for(0ms, a, b)) {
      // OK, a and b are both locked
    }
and then someone "helpfully" refactors it into
    if (std::try_lock(a, b)) {
      // OK, a and b are both locked [N.B.: this comment is wrong now]
    }
In fact in the latter snippet the `if` body is entered either if a and b
are both locked *or* if b was not lockable, because std::try_lock returns
-1 on success and 0 or 1 on failure.
Now, if std::try_lock didn't already have this weird int-returning API, I
definitely wouldn't be clamoring for you to add it. It seems like a
confusing, PHP-style API to me. But since it does exist, I think arguably
we should be consistent with it.

> 11. Returns: As if by try_lock_until.

I believe you should completely eliminate sentence 11. The preceding
sentence, "Effects: Equivalent to...", already covers this. Even if it
didn't, we don't say "Returns: As if...".

Nit: "instroduced". Also the typeface changes in the middle of the word
"unlock" in sentence 7.

HTH,
Arthur