On Wed, Jun 21, 2023 at 3:02 PM Smith, Jim via Std-Proposals <
std-proposals_at_[hidden]> 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