Boost logo

Boost :

Subject: Re: [boost] New dependency report
From: Peter Dimov (lists_at_[hidden])
Date: 2014-06-07 18:18:10

Andrey Semashev wrote:
> Ok. Just for the record, the same can be achieved with mpl::bool_, even
> without modification:
> foo(mpl::bool_< is_pointer< int >::value >());

Yes, I know. I even said so a few days ago. That's a bit inconvenient and
considerably less readable though, so people might be reluctant to switch to

> Assuming these things will be in MPL.Core (and I really think we will have
> it, even for sake of improving dependencies of existing libraries), there
> is no benefit of having them in Core as well.

When you say "we will have it", what specific procedure do you imagine that
will cause MPL.Core to come into existence?

I'm not saying that we _should_ not have it. I'm saying that there is a
certain gap between "should" and "will". Who will actually bridge that gap
and accept the responsibility for creating and maintaining MPL.Core?

> We can always drop workarounds in MPL.Core, ...

I'm not sure that it will be that simple, as MPL.Core will be required to
maintain backward compatibility with existing uses of MPL. Those existing
uses are not confined to Boost. Part of the responsibility to which I allude
above will be to not break code without a good reason and to address user
complaints that their code did indeed break as a consequence of the
refactoring. So this is a bit of a constraint. It will not prevent a
significant cleanup, but it will serve as a limitation.

> OTOH, duplication of these components in Core may cause confusion and
> subtle errors (i.e. I provided a specialization for core::true_ and not
> mpl::true_ and my code is silently broken).

Well, maybe. I'd say that people need to realize that there's more than one
bool_. At present, we have at least four - mpl::bool_<B>,
mpl::integral_c<bool, B>, boost::integral_constant<bool, B>,
std::integral_constant<bool, B>.

I of course am fully aware of the problems that duplication causes. It is a

I also understand that adding core::bool_ only for then MPL.Core to offer a
completely adequate mpl::bool_ (at level 2 or even 1) will not result in an
ideal situation as we will then be unable to remove core::bool_ for backward
compatibility reasons. But, well... what if MPL.Core never actually

> If you want to just drop the mpl::bool_ part of the interface from type
> traits, that would be a breaking change, ...

It will be a breaking change in theory, but it need not break any actual
code in practice. But that's not particularly relevant, so no point in
digging into it.

> As for Core, I'm not sure we'll need tag dispatching there at all. The
> same effect can be achieved with simple template specialization on
> constants.

I'm not sure what you're talking about here.

Boost list run by bdawes at, gregod at, cpdaniel at, john at