On Wed, Jun 21, 2023 at 3:02 PM Smith, Jim via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
Yes, actually proposing a non-blocking join() that returns true or false because if join() returns false, the thread is not running.

Need a way to say if(thread_is_running) { ... }, and must keep existing logic already in code so future or promise isn't allowed.

The below is closer to what I intended.

>>> If(t.join_will_notblock()) t.join();

Ah. That has nothing to do with `t.joinable()`. But it is a potentially useful property.
The Concurrency TS proposed to add exactly this feature to `std::future`, under the name `f.is_ready()` (meaning no more or less than "`f.wait()` won't block"):
https://en.cppreference.com/w/cpp/experimental/future/is_ready
It didn't propose the same feature for `std::thread`, but it easily could have.

Anyway, `std::future` kind of died before the Concurrency TS could rescue it. But it wouldn't be a terrible proposal to resurrect just the `.is_ready()` getters on `future` and `thread` — and anything else that might benefit from that kind of getter. As Lee said, there's no implementation difficulty here, and no data race.

Counterargument: The more common C++ library idiom is `.try_lock()`/`.try_acquire()`, which would lead instead to `f.try_get()` and `t.try_join()`. But I doubt that "try" semantics are useful in these cases (especially for `try_join`).

my $.02,
–Arthur