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