[Bug libstdc++/69354] std::thread doesn't support move-only callable objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69354 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #8 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #7) > This is Core 1331, which has been sent to EWG (but they haven't had time to > look at any issues for a long time). Ah, but it was fixed by http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0641r2.html and so works in GCC trunk.
[Bug libstdc++/69354] std::thread doesn't support move-only callable objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69354 Jonathan Wakely changed: What|Removed |Added Last reconfirmed|2016-01-19 00:00:00 |2019-3-14 --- Comment #7 from Jonathan Wakely --- (In reply to Anthony Williams from comment #3) > Are you going to file the DR or shall I? This is Core 1331, which has been sent to EWG (but they haven't had time to look at any issues for a long time). See also LWG 2068.
[Bug libstdc++/69354] std::thread doesn't support move-only callable objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69354
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-01-19
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
std::thread is doing the right thing, the problem is definitely in tuple:
#include
struct MoveOnly
{
MoveOnly(MoveOnly&) =delete;
MoveOnly& operator=(MoveOnly&) =delete;
MoveOnly(MoveOnly&& ){}
MoveOnly(){}
};
std::tuple t{ MoveOnly{} };
[Bug libstdc++/69354] std::thread doesn't support move-only callable objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69354
--- Comment #2 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #1)
> MoveOnly(MoveOnly&) =delete;
This is not caused by the faxct it's move-only, but by the unconventional
non-const parameter on the deleted copy constructor. If it's a const reference
then move-only types work as expected (and as widely tested in the testsuite!)
I'm tempted to call it a core defect that the defaulted copy constructor
doesn't just get deleted here:
struct MoveOnly
{
MoveOnly(MoveOnly&) =delete;
MoveOnly(MoveOnly&& ){}
MoveOnly(){}
};
struct D : MoveOnly {
D(const D&) = default;
D(D&&) = default;
D() = default;
};
The base class has a deleted copy ctor, so who cares that the derived class
defaults it with a different signature, it should just delete it in the derived
class too. However, 12.8 [class.copy] p11 (11.2) doesn't apply here.
[Bug libstdc++/69354] std::thread doesn't support move-only callable objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69354 --- Comment #3 from Anthony Williams --- I hadn't noticed I had omitted the const! Surely the intent of 12.8p11.2 is that if you can't actually copy the bases and/or members with the specified signature then the defaulted copy constructor is deleted? Are you going to file the DR or shall I? Potential core defect aside, I still think this class should work with std::thread, as it fits the MoveConstructible requirement.
[Bug libstdc++/69354] std::thread doesn't support move-only callable objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69354 Ville Voutilainen changed: What|Removed |Added Status|NEW |ASSIGNED CC||ville.voutilainen at gmail dot com Assignee|unassigned at gcc dot gnu.org |ville.voutilainen at gmail dot com --- Comment #5 from Ville Voutilainen --- I'll see what I can do. :)
[Bug libstdc++/69354] std::thread doesn't support move-only callable objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69354 --- Comment #6 from Jonathan Wakely --- We can't even partially specialize the _Head_base type on whether the element type is M(M&) or M(const M&) because we can't detect which signature has been deleted by using something like is_constructible.
[Bug libstdc++/69354] std::thread doesn't support move-only callable objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69354 --- Comment #4 from Jonathan Wakely --- (In reply to Anthony Williams from comment #3) > I hadn't noticed I had omitted the const! It took me a while to spot it too! > Surely the intent of 12.8p11.2 is that if you can't actually copy the bases > and/or members with the specified signature then the defaulted copy > constructor is deleted? One would think so, yes. > Are you going to file the DR or shall I? I'll do so. > Potential core defect aside, I still think this class should work with > std::thread, as it fits the MoveConstructible requirement. Yes, I tried to find a way to declare this INVALID but couldn't find one :-) The fact we use std::tuple in std::thread is purely an implementation detail and any limitation in our tuple shouldn't prevent valid uses of std::thread.
