ALRIGHT HERE'S A FUN ONE FOR YALL
The behavior I want to talk about here is related to this proposal which was accepted into the standard for the... 2020 version? I think?
The behavior in question is the idea that, if you have a type whose copy constructor takes a nonconst reference to the object being copied, and try to aggregate it into a type like std::tuple, the program (prior to C++20) would not compile. The reason this happens is because std::tuple's copy constructor takes a const reference to the tuple being copied, but constness can't be upheld if the objects being stored in the tuple themselves are mutated upon being copied.
The proposal in question says that this behavior is dumb and in this case (like the code I wrote above) the program should still compile as long as no copies of the tuple in question take place.
According to the cpp compiler support table, GCC has "partial support" for this feature and clang has "full support."
However, if you try to compile the above program with, say,
"g++ -Wall -Wextra test.cpp"
you'll find that it works just fine. This isn't surprising, "partial implementation" means some instances of this behavior should work but what IS surprising is it even works if you do
"g++ -std=c++17 -Wall -Wextra test.cpp"
which... what? Isn't that before the feature was... implemented?
Okay whatever but what IS strange is that if you run
"clang++ test.cpp"
you get a compilation error??? I thought clang was supposed to fully support this feature?
(This is on g++ v15.2.1 and clang v21.1.6)
So yeah idk what's going on here lol :3
Moral of the story, don't have side effects in your copy constructors. Maybe. Idk lol :3
