Lot's of features has been added since last readme update. There is also a lot to clarify and fix.

It may be convinient to add possibility for all operators (for which it makes sense ofc) to use two argument functions, where first would be keys and the second one would be mapped values. Currently given operators would need work:

• filter
• transform

Operator take

Input

Enumerable and unsigned number.

Output

Enumerable containing given numer of elements from the beginning of the enumerable argument.

Example

const auto input1 = { 1, 2, 3, 4, 5 };
const auto out = intput1 | take(2);
//out should contain 1, 2

Enumerable 'infinite'

Input

Any value with copy constructor

Output

Enumerable returning the input value at every iteration.

Example

for(const auto &i : infinite(3))
    cout << i << ", "; //should print 3, 3, 3, 3 .........

The title is pretty self explanatory ;)

Blockers:
[x] #56
[x] #57
[ ] #59

Operator keys

Input

Associable enumerable.

Output

Enumerable to iterate through keys of given associable enumerable.

Example

const auto input = { std::make_pair(1, 2), std::make_pair(3, 4), std::make_pair(5, 6) };
const auto output = input | keys;
for(const auto &i : output)
    std::cout << i;
//output should be 1, 3, 5

Currently Visual Studio at AppVeyor complains about `operator decltype(...)' in fold_left_* operators.

Operator mapped_values

Input

Associable enumerable.

Output

Enumerable to iterate through mapped values of given associable enumerable.

Example

const auto input = { std::make_pair(1, 2), std::make_pair(3, 4), std::make_pair(5, 6) };
const auto output = input | keys;
for(const auto &i : output)
    std::cout << i;
//output should be 2, 4, 6

Currently many operations are using "holders" to construct operators later. There should be more OO solution used - instead of holders factories should be used with create method.

Currently, every time iterator is dereferenced whole computation process is required. Cache operator would store the data at some point to avoid computing same data multiple times.

Operator copy_to

Input

Enumerable and output iterator to copy into.

Output

No output. The outcome is that all elements from enumerable are copied into the output iterator,

Example

const auto input = { 1, 2, 3, 4, 5, 6 };
std::vector<int> output; 
input | copy_to(std::back_inserter(output));
//vector output should contain 1, 2, 3, 4, 5, 6

Currently some data (mostly in holders) is passed always by value. It is not very bad, but can be fixed using perfect forwarding.

Currently infinite generates sequence of single value. It would be nice to be able to generate repeating sequence of values like {1, 2}.

"Deep" versions of algorithms would work for nested enumerables without breaking this nested hierarchy. For example:

const auto input = { (std::vector{1, 2}), (std::vector{3, 4, 5}), (std::vector{6}) };
const auto output1 = input | deep_filter([](const auto &i){ return i >=2; });
// output1 is now {{2}, {3, 4, 5}, {6}}

const auto output2 = input | deep_filter([](const auto &i){ return i < 6; });
// output2 is now {{1, 2}, {3, 4, 5}, {}}

I will gladly disscuss pros and cons of keeping the empty containers inside hierachy.

Our TODO list is:

• transformed
• sorted
• filtered
• flattened

Operator fold_left

Input

Enumerable and folding functiion. Optionally folding start value
Enumerable, folding function and folding start value. If start value is not given, default value of the enumerable value type is used as initial.

Output

Folded value depending on folding function.

Additional info

As fold is not so easy to describe here is given quite good explanation:
https://en.wikipedia.org/wiki/Fold_(higher-order_function)

Example 1

const auto input = { 1, 2, 3, 4, 5, 6 };
//sum example
const auto output = input | fold_left((const auto &a, const auto &b)[]{ return a + b; });
//output should be 21

Example 2

const auto input = { 1, 2, 3, 4, 5, 6 };
//sum example
const auto output = input | fold_left((const auto &a, const auto &b)[]{ return a + b; }, 2/*fold initial value*/);
//output should be 23

child of #17

As the title says, it should be possible to iterate backwards on the enumerables .

They act as code bloat currently and rarerly are even compileable - let's remove them.

Currently operator count requires a predicate to count specific data. It should be possible to count all the elements regardless of any predicate.

Namespaces and names of directories should be the same. Currently it is not unified

Currently constexpr is not used - but it should be to move some of evaluations to the compile time.

Currently most of these warnings are order of initailization lists in constructor. This can be easily fixed

There should be operator.hpp for all headers in operator directory, sink.hpp for all in sink directory and so forth. Additionaly there should be a tpl.hpp including all of these.

Currently only Travis is supported - Windows builds would be helpful.

Currently there are two versions of fold_left, because MSVC has issues with auto conversion operator. Even though there should be way to merge them in the way that both compilers will accept the code.

Currently sorted_sequence caches the input only once. It can be a problem when dealing with mutable input enumerables. All in all, it should sort data everytime it is requested iterator.

Currently all "holders" are held in detail namespace which causes problems with operator| usage. Simply enough - the detail namespace aruond those should be removed.

Currently the whole "flow" of data from source through operators to sinks is required for operator | to work properly. It would be useful to be able to compose more complex operators using the ones provided without need to specify input and/or output.

operator++ in flatten operator causes crash at VS2017 x64 with Debug enabled. This should be fixed immidiatelly.

Root should be directory include. Inside should go tpl directory with its contents. Operation directory sholud be renamed to operator.

Operator reverse

Input

Enumerable.

Output

Enumerable with reversed order of elements.

Example

const auto input = { 1, 2, 3, 4, 5, 6 };
//sum example
const auto output = input | reverse;
//output should contain { 6, 5, 4, 3, 2, 1 };

Remarks

This feature depends on implementation of:

• #8 Implementation of reverse iterators for enumerables

It looks like these namespaces give more problems than gain. They should be removed and their contents moved to tpl namespace.

For code to be more readable it should be used with internal naming - every Container in code should be raplaced with Enumerable.

As far as I know the code should be compilable under VS2015 - and so CI should also cover this compiler/ide.

TODO list (checked are already done):

• trait for checking if given type is enumerable
• trait for checking if given type is associative
• proper typedefs concerning associative enumerables
• function types traits
• enumerable traits

I started with this name, but let's be honest - it is not very good. Perhaps you can come up with something better

gcc4.9 has theoretically all the features this library needs to work. We should try to add it to the matrix.

Currently there is quite a lot files in tpl directory. It should have few subdirectories like: sources, operators, sinks with corresponding headeres put inside them.

Operator flatten

Input

Enumerable of enumerables of generic type T.

Output

Enumerable containing all elements of the internal enumerables from input.

Example

const auto input = { (std::vector{1, 2}), (std::vector{3, 4, 5}), (std::vector{6}) };
const auto output = input | flatten;
for(const auto &i : output)
    std::cout << i;
//output should be 1, 2, 3, 4, 5, 6

Currently tests are only made on gcc7, but the code should also be runnable (and tested) at gcc5 and gcc6.

Currently there is no code coverage control. Yet for the code to be tested well the coverage should be measured and controlled all the time.

Enumerable generator

Input

Single argument function returning type convertible to its argument and initializing value of the same type as the function.

Output

Enumerable returning value "generated" by the function. Generator passes previous generated value to the function which builds up new value from it and returns it.

Example

for(const auto &i : generator([](const auto &i){ return i+i; }, 1))
    cout << i << ", "; //should print 1, 2, 4, 8, 16, ......

These two operators have generally a lot of common code, they should be made a template depending on function to extract value from pair.

Operator drop

Input

Enumerable and unsigned number.

Output

Enumerable from the argument without given numer of elements from beginning.

Example

const auto input1 = { 1, 2, 3, 4, 5 };
const auto out = intput1 | drop(2);
//out should contain 3, 4, 5

Currently callables are store in lambdas by value but if callables were pure they could be stored by reference. This requires further research

If gcc compiles the code, the clang should also be checked. Probably versions 3, 4 and 5 would be sufficient

Many operations in iterators is repeatable. It would be wise to create common base for iterators.

Operator zip

Input

Two enumerables

Output

Enumerable coresponding to "zipping" of two enumerables. For example from zip({1, 2}, {'a', 'b'}) -> { (1, 'a'), (2, 'b') }. In case zipped enumerables have different number of elements, the longer is truncated at the end.

Example

const auto input1 = { 1, 2, 3 };
const auto input2 = { 'a' , 'b', 'c', 'd' };
const auto zippped = zip(input1, input2);//zipped should contain { (1, 'a'), (2, 'b'), (3, 'c') }
//optionally input1 | zip(input2)