Subject: Re: [boost] Boost 1.61.0 Release Candidate 1
From: Stephan T. Lavavej (stl_at_[hidden])
Date: 2016-05-06 11:07:19
> Can you avoid using 1-tuples internally? 2-tuples aren't affected by this breaking change.
> 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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk