On Fri, 1 Oct 2021 at 21:26, Ville Voutilainen wrote: > > On Fri, 1 Oct 2021 at 23:19, Jonathan Wakely via Libstdc++ > <libstd...@gcc.gnu.org> wrote: > > > > This adds a non-standard extension to support initializing a > > std::jthread with a pointer to a member function that expects a > > stop_token to be added to the arguments. That use case is not supported > > by C++20, because the stop_token would get added as the first argument, > > which is where the object argument needs to be to invoke a pointer to > > member function. > > Yeah, and the use-case is supported by applying a wrapper that does > the right kind of argument binding, like > shown in the BZ. Why are we doing this?
The lambda workaround is not as convenient as having it Just Work. so it seemed like a useful extension to try, with no downside. It doesn't even change the is_constructible<thread, ...> result , because the std::thread constructor isn't constrained, so is_constructible<thread, ...> is true for nearly all arg types anyway. The only "non-conformance" is that we don't diagnose the is_invocable_v<decay_t<F>, decay_t<Args>...> requirement if F is a pointer-to-member-function. Maybe I should have sent it as an RFC, or just left it in my fork not pushed to trunk. If a proposal comes before the committee and gets rejected then we can remove it again.
