Issue 3563: keys_view example is broken (original) (raw)

This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++23 status.

3563. keys_view example is broken

Section: 25.7.23.1 [range.elements.overview] Status: C++23 Submitter: Barry Revzin Opened: 2021-05-29 Last modified: 2023-11-22

Priority: 3

View all issues with C++23 status.

Discussion:

In 25.7.23.1 [range.elements.overview] we have:

keys_view is an alias for elements_view<views::all_t<R>, 0>, and is useful for extracting keys from associative containers.

[Example 2:

auto names = keys_view{historical_figures}; for (auto&& name : names) { cout << name << ' '; // prints Babbage Hamilton Lovelace Turing }

— _end example_]

Where keys_view is defined as:

template using keys_view = elements_view<views::all_t, 0>;

There's a similar example for values_view.

But class template argument deduction cannot work here, keys_view(r) cannot deduce R — it's a non-deduced context. At the very least, the example is wrong and should be rewritten asviews::keys(historical_figures). Or, I guess, askeys_view<decltype(historical_figures)>(historical_figures)> (but really, not).

[2021-05-29 Tim comments and provides wording]

I have some ideas about making CTAD work for keys_view andvalues_view, but current implementations of alias template CTAD are not yet in a shape to permit those ideas to be tested. What is clear, though, is that the current definitions of keys_viewand values_view can't possibly ever work for CTAD, because R is only used in a non-deduced context and so they can never meet the "deducible" constraint in 12.2.2.9 [over.match.class.deduct] p2.3.

The proposed resolution below removes the views::all_t transformation in those alias templates. This makes these aliases transparent enough to support CTAD out of the box when a view is used, and any questions about deduction guides onelements_view can be addressed later once the implementations become more mature. This also makes them consistent with all the other views: you can't writeelements_view<map<int, int>&, 0> orreverse_view<map<int, int>&>, so why do we allowkeys_view<map<int, int>&>? It is, however, a breaking change, so it is important that we get this in sooner rather than later.

The proposed resolution has been implemented and tested.

[2021-06-14; Reflector poll]

Set priority to 3 after reflector poll in August. Partially addressed by aneditorial change.

Previous resolution [SUPERSEDED]:

This wording is relative to N4885.

  1. Modify 25.2 [ranges.syn], header <ranges> synopsis, as indicated:

    […]
    namespace std::ranges {
    […]

    // 25.7.23 [range.elements], elements view
    template<input_range V, size_t N>
    requires see below
    class elements_view;

    template<class T, size_t N>
    inline constexpr bool enable_borrowed_range<elements_view<T, N>> = enable_borrowed_range;

    template
    using keys_view = elements_view<views::all_t<R>, 0>;
    template
    using values_view = elements_view<views::all_t<R>, 1>;

    […]
    }

  2. Modify 25.7.23.1 [range.elements.overview] as indicated:

    -3- keys_view is an alias for elements_view<~~views::all_t<~~R~~>~~, 0>, and is useful for extracting keys from associative containers.

    [Example 2:

    auto names = keys_view{views::all(historical_figures)};
    for (auto&& name : names) {
    cout << name << ' '; // prints Babbage Hamilton Lovelace Turing
    }

    — _end example_]

    -4- values_view is an alias for elements_view<~~views::all_t<~~R~~>~~, 1>, and is useful for extracting values from associative containers.

    [Example 3:

    auto is_even = [](const auto x) { return x % 2 == 0; };
    cout << ranges::count_if(values_view{views::all(historical_figures)}, is_even); // prints 2

    — _end example_]

[2021-06-18 Tim syncs wording to latest working draft]

The examples have been editorially corrected, so the new wording simply changes the definition of keys_view and values_view.

[2021-09-20; Reflector poll]

Set status to Tentatively Ready after six votes in favour during reflector poll.

[2021-10-14 Approved at October 2021 virtual plenary. Status changed: Voting → WP.]

Proposed resolution:

This wording is relative to N4892.

  1. Modify 25.2 [ranges.syn], header <ranges> synopsis, as indicated:

    […]
    namespace std::ranges {
    […]

    // 25.7.23 [range.elements], elements view
    template<input_range V, size_t N>
    requires see below
    class elements_view;

    template<class T, size_t N>
    inline constexpr bool enable_borrowed_range<elements_view<T, N>> = enable_borrowed_range;

    template
    using keys_view = elements_view<views::all_t<R>, 0>;
    template
    using values_view = elements_view<views::all_t<R>, 1>;

    […]
    }

  2. Modify 25.7.23.1 [range.elements.overview] as indicated:

    -3- keys_view is an alias for elements_view<~~views::all_t<~~R~~>~~, 0>, and is useful for extracting keys from associative containers.

    [Example 2: … — _end example_]

    -4- values_view is an alias for elements_view<~~views::all_t<~~R~~>~~, 1>, and is useful for extracting values from associative containers.

    [Example 3: … — _end example_]