Re: [boost] New dependency report

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

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

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 
materializes?

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