Re: [boost] New dependency report

Subject: Re: [boost] New dependency report
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2014-06-07 20:15:54

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();
  };

  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.