[FEATURE] views::zip

[eseiler]

Follow-up:

• Benchmark here
• More tests
• Conditional explicit and noexcept specifiers for common_pair and common_tuple

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated
seqan3	✅ Ready (Inspect)	Visit Preview	May 28, 2022 at 1:46PM (UTC)

[codecov]

Codecov Report

Merging #2971 (823ad77) into master (99a2299) will increase coverage by 0.03%.
The diff coverage is 100.00%.

❗ Current head 823ad77 differs from pull request most recent head 8ed96cb. Consider uploading reports for the commit 8ed96cb to get more accurate results

@@            Coverage Diff             @@
##           master    #2971      +/-   ##
==========================================
+ Coverage   98.14%   98.18%   +0.03%     
==========================================
  Files         269      272       +3     
  Lines       11783    11991     +208     
==========================================
+ Hits        11565    11773     +208     
  Misses        218      218              

Impacted Files	Coverage Δ
include/seqan3/utility/tuple/common_pair.hpp	100.00% <100.00%> (ø)
include/seqan3/utility/tuple/common_tuple.hpp	100.00% <100.00%> (ø)
include/seqan3/utility/views/zip.hpp	100.00% <100.00%> (ø)
...etail/alignment_matrix_column_major_range_base.hpp	100.00% <0.00%> (ø)
...matrix/detail/advanceable_alignment_coordinate.hpp	96.00% <0.00%> (+0.16%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 99a2299...8ed96cb. Read the comment docs.

[eseiler]

@seqan/core

Edit: Fixed by handling iterator_category

Click for previous post

I had to change some concept in the alignment code to make gcc10 work:

template <typename t>
concept indexed_sequence_pair_range =
#if defined(__GNUC__) && (__GNUC__ == 10)
    true;
#else
    std::ranges::forward_range<t> &&
    requires (std::ranges::range_value_t<t> value)
    {
        requires tuple_like<decltype(value)>;
        requires std::tuple_size_v<decltype(value)> == 2;
        requires sequence_pair<std::tuple_element_t<0, decltype(value)>>;
        requires std::copy_constructible<std::tuple_element_t<1, decltype(value)>>;
    };
#endif

This concept is quite ubiquitous in the alignment code (though it also compiles fine if you just use typename).

We also have a type trait

template <typename sequence_pairs_t>
//!\cond
    requires sequence_pair_range<std::remove_reference_t<sequence_pairs_t>>
//!\endcond
struct chunked_indexed_sequence_pairs
{
    //!\brief The transformed type that models seqan3::detail::indexed_sequence_pair_range.
    using type = decltype(views::zip(std::declval<sequence_pairs_t>(), std::views::iota(0)) | views::chunk(1));
};

In short, chunked_indexed_sequence_pairs::type should be a range over tuples.

chunked_indexed_sequence_pairs::type models indexed_sequence_pair_range before this PR on gcc10, and with this PR on gcc11+.

The type is something like views::take<ranges::subrange<views::zip... (take and subrange originate from the chunk implementation) when broken.
Here, the value type is that of views::take and this is most certainly not a tuple.

My guess is that there's something in range-v3 that "collapses" the views and returns the value type of the zip view.
With gcc11, there is more std ranges stuff, and it works there - maybe some time erasure stuff.

I would just deactivate the concept on gcc10 and revisit it once we have a chunk_view implementation.

[eseiler]

Because the STL says so :o I haven't looked, but I'd say partly because it would incur cost (unless static), and partly because you need it to define the view itself.

However, I'm happy to revisit the namespace stuff (maybe after the join view is in seqan3). But for now, I really want to keep it separated from the rest of seqan3.

[smehringer]

taken from the std documentation :)

Suggested change

	/*!\brief A view adaptor that produces a tuple-like value of all passed views.
	/*!\brief A view adaptor that takes several views and returns tuple-like values from every i-th element of each view.

?
I think your sentence sounds like it forms a tuple of views, not a tuple of view elements.