On Wed, Aug 27, 2025 at 4:42 PM Ted Lyngmo via Std-Proposals <std-proposals@lists.isocpp.org> 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