Re: [boost] Boost 1.61.0 Release Candidate 1

Subject: Re: [boost] Boost 1.61.0 Release Candidate 1
From: Stephan T. Lavavej (stl_at_[hidden])
Date: 2016-05-06 11:07:19

[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