sum_type_alternatives<ST>::type requirements

[viboes]

While in the D0050 proposal it is said that it is enough that the type specialize tuple_size and tuple_element, the implementation today works only if the the product type sum_type_alternatives<ST>::type is meta::types<Ts...>. In addition the tuple like type must be cheap to copy (I don't know if the last is a real constraint or one of my implementation).

This is because internally I'm using the class meta::types.

Either, I will need to restrict the type of sum_type_alternatives<ST>::type to meta::types in the proposal and describe it, or add in the proposal the cheap copy constraint and change the implementation. This change in the implementation would be quite disturbing as we can not use pattern matching to manage with recursion on the alternative types.

What others think?

[cppljevans]

I think there's some typos in your comment above.

'cheep to copy' should be 'cheap to copy'
'pattern patching' maybe should be 'pattern matching'?

BTW, before I can comment on such issues, I'd need to
better understand the implementation, especially how
match in yafpl/v1/functional/match.hpp works.
What I find puzzling is how the 'abstract' types&values
are 'reified' into the 'concrete' types&values
(I think you used some other terms for this in
your paper). For example, how is the 'abstract'
value, variant<T1,T2> v_abs(T1{}), 'reified' into the
concrete value, T1 v_conc? I've been looking
at match.hpp and I'm guessing that on line 79:

  template <class Final, class R, class F, class... DTs, class...

STs, class T, class... Ts>
class applier<Final, R, F, tuple<DTs const&...>, tuple<STs
const&...>, types<T, Ts...>>
: public applier<Final, R, F, tuple<DTs const&...>, tuple<STs
const&...>, types<Ts...>>
{

the DTs... are maybe the concrete types, the STs... are the abstract
types; however, I've no idea what the Ts... are.

Could you maybe supply some comments to the code to help me
understand it?

TIA.

-Larry

[viboes]

Typos fixed.

I will add some comments or replace by better names.

[cppljevans]

I couldn't find the definition for index_sequence_for used here:

https://github.com/viboes/tags/blob/master/include/yafpl/v1/functional/match.hpp#L93

I tried with grep, as shown below:

-*- mode: compilation; default-directory: "~/prog_dev/boost/git/tags/" -*-
Compilation started at Sat Sep 19 05:14:35

find . -name \*.hpp -exec grep index_sequence_for {} \; -ls
          dispatch(index_sequence_for<DTs...>(), v, index_sequence_for<STs...>());
11944712   20 -rw-rw-r--   1 evansl   evansl       9863 Sep 19 00:53 ./include/yafpl/v1/functional/match.hpp

Compilation finished at Sat Sep 19 05:14:36

Could you let me know where I can find the defintion.
I did try to google for it thinking it was in the standard
somewhere, but failed to find anything :(

OOPS. Just compiled code with std::index_sequence_for<int,int,int>
and it worked with -std=c++14. I guess there must be a using
namespace std somewhere in match.hpp or its #include's.

Sorry for noise.

-regards,
Larry

[viboes]

This is c++14 from the standard

  template<class... T>
    using index_sequence_for = make_index_sequence<sizeof...(T)>;

You are right, I will check for the using namespace std;

[viboes]

Update done to qualify anything on std::

[cppljevans]

Vicente, your OP mentioned a possible problem with tuple copying:

In addition the tuple like type must be cheap to copy

The code here:

https://github.com/cppljevans/variadic_templates/blob/master/sandbox/indices_val2type/indices_val2type.cpp

avoids repeated copying of tuples because it calculates the indices to
the tuples' variants without any reference to the actual tuple of variants, and then
uses those indices all at once on the single copy of the tuple of variants to get
the actual arguments to the functor.

As indicated in the comments, it compiles and runs on gcc5.2.0 and clang3.77.

HTH.

-Larry

[viboes]

I believe that I see how this works.

I wonder if instead of passing the tuple of alternatives is not enough to pass the size, and recurse until 0. Each recursion will add the operator associated to the nth element of the alternatives of the associated Sum Type

Thanks Larry for the idea.

[cppljevans]

On 09/27/2015 09:55 AM, Vicente J. Botet Escriba wrote:

I believe that I see how this works.

I wonder if instead of passing the tuple of alternatives is not enough
to pass the size, and recurse until 0. Each recursion will add the
operator associated to the nth element of the alternatives of the
associated Sum Type

Sorry, I don't understand.
Could you please explain a little more?

Thanks Larry for the idea.

You're welcome, Vicente.

BTW, I've updated the code:

https://github.com/cppljevans/variadic_templates/blob/master/sandbox/indices_val2type/indices_val2type.cpp

by adding more comments and hopefully making it
more efficient. I'd appreciate any comments about
how to improve it.

-Larry