On Sun, 9 Jul 2023, 17:32 Giuseppe D'Angelo via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> Il 09/07/23 18:03, Kilian Henneberger via Std-Proposals ha scritto:
> > The workaround is fairly simple. Nevertheless, I think that the current
> > behavior of std::jthread's constructor is surprising. Personally, I
> > would have expected, that if I pass a member function pointer to the
> > constructor of std::jthread, that it then checks for
> > is_invocable_v<decay_t<F>, decay_t<Arg0>, stop_token,
> > decay_t<OtherArgs>...>. This idea has already been discussed here:
> > https://www.mail-archive.com/gcc-bugs_at_[hidden]/msg690638.html . As a
> > result, it got implemented as an extension to libstdc++
> > (
> https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/std/thread#L246).
> I am almost sure it would be worth standardizing this extension. But I
> first want to float the idea here and collect some feedback.
>
> Unless this was intended ("by design"), this sounds almost like a
> library defect¹. Have you tried contacting the authors of the jthread
> proposal (wg21.link/p0660) and asking them if this was on purpose?
>


Nico thought it was supposed to work and was surprised to learn the spec
made it invalid. See the comments at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100612

The lambda workaround is simple enough that I didn't bother proposing it.