On May 6, 2016 02:31, "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.
The specification change is the removal of the converting constructor for 1-tuples. The thing is, signals2 never did any converting construction of tuples. It was a straight copy construction of some templated function arguments. The compiler error was using the converting tuple constructor at all.
Anyway, boost::signals2, boost::any and boost::variant seem like fairly
important
parts of Boost, there are already two independent bug reports,
To be clear, the libraries are not completely broken even with the broken compiler. It's just the specific case of a 1 argument signal whose parameter type is a boost::any or similar. And the bug is not restricted to boost, one of the tickets has a boost-free test case that demonstrates the compiler's problem with 1-tuples.
and having this problem on the most recent version of a popular compiler is somewhat embarrassing.
I agree it's somewhat embarrassing - for MSVC.
If it can be solved by delaying the release by a day or so, it seems reasonable.
Isn't the release already a week or so behind schedule?
Do you see any reason why this commit might explode on master?
No I think it is a low risk commit. Sorry for the ranting, I'm done now, carry on :)