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

Subject: Re: [boost] [type_traits] Rewrite and dependency free version
From: Beman Dawes (bdawes_at_[hidden])
Date: 2015-01-14 21:13:35

On Wed, Jan 14, 2015 at 2:58 PM, John Maddock <boost.regex_at_[hidden]> wrote:
> I'm going to throw this out there to see what folks think:
>
> In a branch called "Version2", see
> https://github.com/boostorg/type_traits/tree/Version2 is a partially
> rewritten type_traits lib: it doesn't yet contain all the traits of the old
> one, but there's a pretty good selection to test.
>
> The main pros for this version are:
>
> 1) Zero dependencies other than Boost.Config.
> 2) No horrible macro-obfuscation - all "real code", making it easier to read
> and maintain.
> 3) Substantially reduced template instantiations where practical - often
> half as many as before.
> 4) Substantially reduced #includes - the aim is that all files should
> include only what they need and no more - with what's needed determined by
> the actual implementation variant when appropriate.  There were also a lot
> of spurious #includes left over from old workarounds no longer used.

Every one of those is a big win.

>
> The main cons:
>
> 1) I don't know what I've broken, but surely something, you can help by
> testing but I would guess we would never be 100% sure it's all right until
> it's out in the field.  This is the main reason for avoiding this until now.
> 2) MPL interoperability should still work, but files which expect
> type_traits headers to have included mpl ones will be broken unless they
> explicitly include what they need.
> 3) Current MPL inter-operability is fragile see
> https://github.com/boostorg/type_traits/blob/Version2/include/boost/type_traits/integral_constant.hpp
> 4) Function dispatching to an mpl::bool_ involves an (inline) function call
> where as the old inheritance scheme did not.  This should mostly disappear
> once optimizations are turned on, but is still a potential issue for some
> folks I suspect.
> 5) I haven't got to the "difficult" headers like common_type.hpp yet.
> 6) Whatever I've forgotten ;)

Those don't seem like showstoppers, either individually or in
aggregate. Careful testing, and social engineering like announcing the
1.58 beta more widely than usually will help, too.

>
> Of course (2), (3) and (4) could be solved by making mpl's bool.hpp some
> kind of "core" header.
>
> So... what I need from you kind folks is:
>
> * Is this the right way forward?

+1.

The potential risks seem minor compared to the known gains.

--Beman