Re: [boost] New dependency report

Subject: Re: [boost] New dependency report
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2014-06-07 14:35:57

On Sat, Jun 7, 2014 at 10:00 PM, Peter Dimov <lists_at_[hidden]> wrote:
> Andrey Semashev wrote:
>
>> Pulling type traits to Core doesn't sound good, it's better to create a
>> separate submodule for it.
>
> I think that you misunderstand. I do not intend to put type traits in Core.
> The is_pointer definition in the example is part of the test for bool_. It
> demonstrates that bool_ can dispatch without it being coupled to the
> definition of the trait - which can come from core_type_traits, from std, or
> from a user specialization.

You're right, I did misunderstood. So you're proposing to add bool_ to Core?

>> It's still a partial solution...
>
> When you say that it is a partial solution, what problem do you have in mind
> it is a partial solution for?

I was thinking you were proposing a replacement for deriving traits from bool_.

>> ... since
>>
>>  f(is_pointer< int >::type());
>>
>> is also valid with the current implementation.
>
> Well, so is
>
>    is_pointer<int>::value_type x = is_pointer<int>::type::type();
>
> but I'm not sure what is the practical impact of these examples.

Well, I surely did use the nested ::type type somewhere.

My point was that your proposed bool_ doesn't fully reflect the
current interface, so it can't replace it. In that case, is there a
point to it? TypeTraits will still derive from mpl::bool_. We don't
need another bool_ in Core (yet) and TypeTraits.Core would be enough
for us. And if we need bool_ I'd probably prefer it in MPL.Core, and
it should be the same bool_ TypeTraits derive from. I wouldn't like us
having multiple different bool_s in multiple libraries.