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
> 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?
The potential risks seem minor compared to the known gains.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk