deprecate seqan3::views::get

[marehr]

Tasks

• deprecate seqan3::views::get
• remove usage from our tests/snippets
• add changelog entry

From 7a7926a6daebed3bec20c7bebe72abf5c7c38a50 Mon Sep 17 00:00:00 2001
From: marehr <marehr-github@marehr.dialup.fu-berlin.de>
Date: Sun, 18 Apr 2021 12:47:48 +0200
Subject: [PATCH 04/35] TODO: [MISC] deprecate seqan3::views::get

---
 include/seqan3/range/views/get.hpp | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/include/seqan3/range/views/get.hpp b/include/seqan3/range/views/get.hpp
index ac28a3b9a..0adc3c6d2 100644
--- a/include/seqan3/range/views/get.hpp
+++ b/include/seqan3/range/views/get.hpp
@@ -61,6 +61,18 @@ namespace seqan3::views
  *
  * \include test/snippet/range/views/get.cpp
  * \hideinitializer
+ *
+ * \deprecated same as std::views::elements<index> if index is a size type,
+ *             or std::views::transform([](auto && tuple)
+ *             {
+ *                 using std::get;
+ *                 return get<index>(tuple);
+ *             });
  */
 template <auto index>
 inline auto const get = std::views::transform([] (auto && in) -> decltype(auto)
-- 
2.31.1

[marehr]

We decided to rename it to seqan3::views::elements and move it to utility, because the standard does not allow custom tuple types right now. The ultimate goal is to get that behaviour into the standard and simply remove it :)

I filed an issue at gcc and after that I wrote a LEWG-issue to the standard

std::views::elements only accepts types that are defined on std::get

Dear LWGChair,

this is my first time reporting, so I'm not too familiar how to do this, please be kind!

std::views::elements does not work with custom-tuple types that have otherwise working structured bindings (see [1] for an example).

Right now, [2] defines get-element(const iterator_t<Base>& i) that calls get<N>(*i); and [3] clarifies that it actually means to call get qualified, i.e. std::get<N>(*i).

Note that Tim Song in [4] suggests that get should be explicitly std::get, but it sounds to me more like a fix to the general problem, that get would otherwise be needed to be called as std::ranges::get and that would be obviously wrong, as an actual requirement.

I think, and here I need some help, it would be good if the standard defines get-element in a way that get will be called unqualified. To allow all tuple types that have working structured bindings, too.

Thank you
Marcel

[1] - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100233
[2] - https://eel.is/c++draft/range.elements#iterator-3
[3] - https://eel.is/c++draft/contents#3
[4] - https://cplusplus.github.io/LWG/lwg-active.html#2818