Subject: Re: [boost] New dependency report
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2014-06-07 20:20:30
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.