Re: [boost] New dependency report

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.