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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk