On Sat, Jun 7, 2014 at 10:00 PM, Peter Dimov
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.