On Sunday 08 June 2014 04:15:54 you wrote:
On Sunday 08 June 2014 01:18:10 Peter Dimov wrote:
Andrey Semashev wrote:
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?
Yes, I probably made that statement overly confident. I'm not the maintainer of MPL nor I have rights to create submodules, so I clearly don't have the upper hand. However, I do think this is the right way to go, and should we take that route I'd be willing to participate in that work.
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.
Surely we will have to maintain interface compatibility of the components we move to MPL.Core (if it is created). But is it that much of a constrain? What kind of changes do you think will be needed and not possible without breaking compatibility? If you're concerned with supporting ancient compilers, then I'd say you shouldn't be as noone requires us to keep the support forever.
I think, at first it will be simply enough to just move the components to the new submodule. This alone will reduce dependencies.
I'd say that people need to realize that there's more than one bool_.
I'm on the opposite end. I think it's better to reduce the fragmentation, it does no good in practice. It's the same as with std::shared_ptr vs boost::shared_ptr - both work and available, used in different places and yet incompatible.
what if MPL.Core never actually materializes?
Let's make it happen then. :)
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.
If you have a tag dispatching code such as:
void foo(mpl::true_); void foo(mpl::false_);
foo(is_pointer< T >());
you can always replace it with template specializations:
template<bool> struct foo { void call(); }; template<> struct foo<false> { void call(); };
Uh, these two call() declarations should be static.
foo< is_pointer< T >::value >::call();
Yes, it's more awkward but it allows to avoid dependencies on MPL and use TypeTraits.Core.
However, I don't see tag dispatching in Core now and I'm not sure it will appear (and need refactoring such as above) in the near future.