Re: [boost] [type_traits] Rewrite and dependency free version

Subject: Re: [boost] [type_traits] Rewrite and dependency free version
From: John Maddock (jz.maddock_at_[hidden])
Date: 2015-02-01 08:36:05

>>> 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.

Please see my other message - a dependency free version of common_type 
is possible for C++11 compilers and/or anything that supports GCC's 
typeof.  That means VC10 or later, and pretty much any GCC (or emulation 
thereof) that we support.  As long as the package manager supports some 
form of "optional dependency", users who need older or more obscure 
compilers can manually fulfil the dependency by downloading Boost.Typeof 
(and dependencies) as well.

But not for the next release - I was thinking of merging to develop 
*after* the next release so as to not destabilize that process - then 
shake down in develop for at least one release cycle before merging to 
release.  In other words in time for the Autumn boost release.

John.

> 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
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>