Isn't this supposed to drop the extra T as well?

good catch, thanks!

Could we move these two back to an internal file, it is not quite 'general' enough :) [ i.e. ROOT implementation detail]

we don't want ROOT type traits in ROOT/TypeTraits? :) note that it does not introduce a dependency on libHisto, it just needs a forward decl

moved back to TDataFrame

What is the difference between TakeFirst and TakeFirstParameter? Do we need both? Can we distinguish them more?

TakeFirst acts on variadic lists of types, e.g. TakeFirst_t<A,B> is A. TakeFirstParameter acts on the parameter list of a template object, e.g. TakeFirstParameter_t<U<A,B>> is A. They do different things, so I would say we "need" them both. I'm open to suggestions regarding the names (TakeFirstType and TakeFirstParameter?). I thought the docs were clear but maybe not?

renamed to TakeFirstType

I suppose your renamed the first one (formely TakeFirst), in which case, this is indeed better. thanks

Can we please rename the test file either TypeTraits.test.cxx (or testTypeTrait.cxx) to distinguish it (beyhond just the directory) from an implementation file? Thanks.

sure

We were using EntityToTestTests.cxx pattern. Having something/test/test*.cxx looks very weird...

Who's "we"? ls */*/test/*.cxx seems to disagree...

I'd have written that as

template<class A,
  class NonConstA = typename std::remove_const<A>::type,
  class ConstA = typename std::add_const<A>::type>
Test(NonConstA::iterator = {},
   ConstA::const_iterator = {},
   NonConstA::iterator = decltype(NonConstA().begin())()
   NonConstA::iterator = decltype(NonConstA().end())(),
   ConstA::const_iterator = decltype(ConstA().begin())(),
   ConstA::const_iterator = decltype(ConstA().end())(),
   bool = typename std::is_same<delctype(*ConstA::const_iterator()), typename add_const<ConstA::value_type>::type>::value,
   bool = typename std::is_same<delctype(*NonConstA::iterator()), ConstA::value_type>::value)

This ensures that

• the container and (const_)iterator are default constructible
• there is a (const_)iterator that matches the return types of begin() and end(), const and non-const versions,
• (const_)iterator can be derefed giving (const) value_type

I see you have more tests in the body. Note that e.g. **piwill trigger a compilation failure if iterator has no deref, instead of returning false, which is why I added checks to the signature. More might be needed.

Thanks for looking into this. This was implemented by @dpiparo so I would ask his opinion too.

Hi @bluehood , @Axel-Naumann I am of course fine with the new implementation!

I don't think we need this in the public part of the type traits. Maybe at least ROOT::Detail:: if not ROOT::Internal? Do you think we'll have more uses?

@pcanal expressed the same concern. I'm outnumbered, so I'll move IsV7Hist back inside TDataFrame's stuff.

done

I would make the generic one empty. Then have a specialization for those T that have a call operator.

will do

Can you spell the result (please use the std wording here) type using result_of and invoke_result, for all cases, moving the arg_types deduction into a helper detail struct that you then partially specialize?

Let me rephrase:

struct foo{
  int operator()(int);
  double operator()(double);
};
using res = typename CallableTraits<foo(float)>::ret_type;

should res be double or should this be ill-formed?

What is the standard wording? result_of and invoke_result contain a type, but I think it would be a confusing name here? boost uses return_type in their function_traits, I can change it to that if you prefer.

Your example should be ill-formed because CallableTraits does not require to specify the argument types, users just pass in a callable object. Supporting the syntax you used might be a nice addition but we have no use for it, at least for now.

Forget what I said - you test the callable, not the expression. Return type is just fine.

You allow for non-member function references but not for member function references. Intentional?

Can you give me an example?

This works:

struct A { void foo() {} };
static_assert(std::is_same<CallableTraits<decltype(&A::foo)>::ret_type, void>::value, "");

Does static_assert(std::is_same<CallableTraits<decltype(A::foo)>::ret_type, void>::value, ""); work?

It does not. Can you ever use decltype(A::foo) anywhere?

Indeed, thanks! Forget this comment, too! :-)

That is a very ... rare ... behavior. Providing this as a general tool might see misuses / misunderstanding of the interface. I'd naively expect that TakeFirstParameter<T> is either empty or ill-formed, instead of mixing template levels... Do you expect generic usage of this? (Do you really know you need this behavior in your use case? I didn't look at it, it seems surprising...)

I agree, I will change the behaviour

done

Can we move this into Experimental::? Then we can just remove it without deprecation, and for now, no other interfaces should be using it.

I am never sure when it comes to ROOT namespaces. Do you mean ROOT::Experimental:: or ROOT::TypeTraits::Experimental:: or ROOT::Experimental::TypeTraits::?

Actually since it is not meant to be used by users (std::index_sequence is), I would put it in ::ROOT::Internal (and move it back to DataFrame unless there is another 'current' user ...

I'll move it back and push for having a backport of std::index_sequence soon :)