[STL]
Can you avoid using 1-tuples internally? 2-tuples aren't affected by this breaking change.
[Vladimir Prus]
Are you suggesting that boost::signals2 specially handles the case of 1 parameter, and starts using 2-tuples in that case? Only Frank can tell how much effort that would be, but it sounds rather intrusive.
I don't know how much work it would be, just that mixing 1-tuples with unconstrained constructors is going to be problematic unless C++17 is significantly reworded. [Frank Mori Hess]
The fixes were just a work-around for a broken compiler
[Vladimir Prus]
I would guess Stephan is in better position to say whether it's indeed broken compiler - from his blog post it sounds like accurate implementation of a broken/suboptimal specification.
As far as I'm aware, VC 2015 Update 2's tuple is a completely accurate implementation of C++17 WP N4582 + LWG 2549's PR (absolutely required for correctness) + LWG 2312's PR (VC has shipped this for years), with the exception of LWG 2485 "get() should be overloaded for const tuple&&" (which was my issue, voted into the WP, just haven't gotten around to implementing it yet). A user recently reported that 1-tuples of UDTs with unconstrained *by-value* constructors can trigger infinite recursion and compiler errors. I analyzed the repro, and it turned out that the infinite recursion is mandated by the current WP Standardese, so I sent a mail to the LWG reflector. (The compiler error appears to be a compiler bug, but if it were fixed, we'd get the infinite recursion AFAICT.) libc++ isn't affected because it has implemented a non-Standard (but probably desirable) constraint for this scenario, which I'm considering. Note that unconstrained by-reference constructors are a different issue. I'm wondering whether we should Standardize explicit tags for disambiguation. In Update 2, I have the (totally internal and undocumented, DON'T use it) ability to tell a tuple, "I am constructing you from exact arguments, perfectly forwarded" or "I am constructing you from another pair/tuple, please unpack its elements". This avoids the 1-tuple problems, which is necessary because our tuple is recursively implemented. If you believe that our tuple isn't following the WP plus the PRs I mentioned, please send me a self-contained repro directly and I'll take a look. If you believe that the WP is defective, please figure out how to fix it. Seriously - there are only so many metaprogrammers in the world, and we need all the help we can get. Thanks, STL