On 18 Jan 2015 14:39, "Peter Dimov"
John Maddock wrote:
2) What do we do about common_type?
Kill it with fire!
I hope you are implying this is done while respecting our deprecation process. It looks like all of the other work can make it into the next release, which is awesome. We can't do this change for the next release without violating our deprecation procedure. I am currently helping companies decide to use Boost and one of the frequent fears is that upgrading Boost consumes a lot of time. I typically point to the deprecation procedure and our efforts to reduce this problem. Sure we still occasionally get it wrong (at least I do) but deliberately compromising external quality factors for internal quality gains is not the way to win customers. I can see the large gains from this considerable work. They are exciting, but let's not violate our procedure on deprecation. Can we get conditionally low dependency by using C++11 where available? I can see that there is still the problem of the publicly documented assertion mechanism. Perhaps the method of compile-time assertion can change without being considered a breaking interface change?
Or, alternatively, move it to TypeOf, although this would not make a good Michael Bay movie.
We can't move it for the next release without breaking our promises to our users. It is all super work and I'm sure that with a little extra thought we can get most or all of these gains in the next release. If we do it without breaking backward compatibility I think our users will be as excited about these changes as we are. Neil Groves _______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost