Re: [boost] Tick: Trait instrospection library for C++14

If the concept is defined in the namespace concepts this is not needed as all these is also in the concepts namespace. Maybe the user should not define its concepts in the same namespace.

As a general purpose library, traits and concepts will need to be defined in different namespaces. For scalability reasons they all can't be defined in the same namespace.

I believe you "sur parolle". What about needing to use placeholders when stating refinement? Why do you need

TICK_TRAIT(is_x, is_Y<_>)

instead of

TICK_TRAIT(is_X, is_Y)

First, placeholder expressions are more flexible than template template parameters. With placeholder expressions I can support non-type template parameters(I don't support them yet), which cannot be done with template template parameters. Secondly, placeholder expressions are more powerful, so say I want to write `is_equality_comparable` trait and have each parameter refine `std::is_default_constructible`, like this: struct EqualityComparable : tick::refinesstd::is_default_constructible<tick::_1, std::is_default_constructibletick::_2> { template auto requires(T&& x, U&& y) -> TICK_VALID( x == y, x != y ); }; template using is_equality_comparable = tick::trait; I believe Eric's framework actually supports placeholders in a similiar way. I believe you can write something like this(assuming we have a `DefaulConstructible` concept already defined): struct EqualityComparable : concept::refines { template auto requires(T&& x, U&& y) -> decltype(concept::valid_expr( x == y, x != y )); }; template using is_equality_comparable = concept::models; Since its not documented, I'm not sure if this entirely correct. Now the same can be done in Tick using the macro based version as well: TICK_TRAIT(is_equality_comparable, std::is_default_constructible<_1>, std::is_default_constructible<_2>) { template auto requires(T&& x, U&& y) -> TICK_VALID( x == y, x != y ); }; The only difference is the placeholders are local. The macro does this by defining a private class, and bringing the placeholders(from `tick::ops`), so something like this: struct private_base_trait_is_equality_comparable : tick::ops { typedef tick::refinesstd::is_default_constructible<_1, std::is_default_constructible<_2>> type; }; struct private_trait_is_equality_comparable : tick::ops, private_base_trait_is_equality_comparable::type { template auto requires(T&& x, U&& y) -> TICK_VALID( x == y, x != y ); }; template using is_equality_comparable = tick::trait; This is all just implementation details.

I don't see the risk to be a valid reason to don't make it public and documenting it. Let the user the choice to don't use macros please.

I would prefer not to give the user something that is broken, and there is no disadvantage to using the macro.

Yes, but the macro needs to generate the is_trait class. Ah, I see it on the code now, you have genrated a variadic template for any is_trait.

template \ struct name \

I would prefer that the concept template had the good template members. Could this be done?

|TICK_TRAIT(is_incrementable, T, refines,|||is_integral<_>|)|

This would get complicated real fast, Especially if the user wanted to define multiple overloads. Also, its starting to look real ugly. If the user wants that kind of control, I think its best not to use the macros.

...

...

Could a concept in your library have a non-type template parameter? It could, but behind scenes it would require wrapping it in a type. Athough, I could work on adding better support for non-type template parameters. Isn't this a consequence of using macros?

No it isn't. It is due to the fact that the `tick::trait`(or `models` if you prefer) only takes type parameters. So the trait can take a non-type parameter, but it would need to be wrapped in a type to pass to `tick::trait` something like this: struct Zeroed : tick::ops { template<class Int> auto requires(Int) -> TICK_VALID( is_true>() ); } template<int N> using is_zero = tick::trait)>; Eric's framework would need to do a similiar thing as well.

This depends where your concept is defined. If it is defined in concepts this works ;-) You have the same namespace problem if the traits are defined in different namespapces.

No, not exaclty. The problem is the user has two different classes to refer to the essentially same thing(ie `Incrementable` and `concepts::Incrementable`). Sometimes the user must refer to it as `Incrementable` and sometimes `concepts::Incrementable`. For simplicity sake, Tick treats the concept as an implementation detail and refers to everything by the trait. The fact that the user may confuse `boost::mpl::is_sequence` and `boost::fusion::is_sequence` is a different problem entirely.

Please could you explain what

returnsboost::fusion::is_sequence<_>(x.foo())

checks? That there is a function member foo and ...

And it returns a fusion sequence, that is `x.foo()` returns something that matches the `boost::fusion::is_sequence` trait(ie `boost::fusion::is_sequence` trait is true for what `x.foo()` returns).

This check the function member foo returns a model of a Fusion sequence, isn't it?

Yes thats true.

...

...

...

Finally, I don't support adding nested types, like in the example you gave with Why? Its better to write it as a seperate trait, like this:

template using addable_result = boost::identity() + std::declval<U>())>;

This allows for better reusability and composability.

All good reasons, but as always is a taste question. Is there something that prevents using them?

Only that the library treats that class as an implementation detail, so it is not always easily accessed. However, in your own library you could make this class available by not using the `TICK_TRAIT` macro. -- View this message in context: http://boost.2283326.n4.nabble.com/Tick-Trait-instrospection-library-for-C-1... Sent from the Boost - Dev mailing list archive at Nabble.com.