[range.elements.overview] LWG 3302: range adaptor objects keys and values are unspecified

[morinmorin]

They are listed in [ranges.syn], but not specified in [range.elements.overview]. Most probably keys would work as elements<0> and values would work as elements<1>. But neither N4830 nor P1035R7 has such specification. I'm not sure if this issue can be resolved editorially.

Additionally, there are no index entries for keys_view and values_view.

[jensmaurer]

That sounds non-editorial.

[morinmorin]

If you want me to submit an LWG issue, I'll take care of it.

[jensmaurer]

That would be nice. Missing descriptions are not editorial.
(Missing index entries are, though.)

[morinmorin]

OK, I'll do that today. Thanks for the help!

[CaseyCarter]

Poor Chris revised P1035 no less than 16 times in Cologne. IIRC we wanted to specify keys and values directly in the synopsis simply as names for elements<0> and elements<1>. It looks like we made it half way there by striking [range.keys.adaptor] and [range.values.adaptor] - which specified views::keys and views::values - but failed to make the corresponding changes to the synopsis.

@morinmorin, if I may suggest a proposed resolution for your issue, I believe our intent was:

Change [ranges.syn] as follows:

 template<class R>
   using keys_view = elements_view<all_view<R>, 0>;
 template<class R>
   using values_view = elements_view<all_view<R>, 1>;
 
 namespace views {
   template<size_t N>
     inline constexpr unspecified elements = unspecified;
-  inline constexpr unspecified keys = unspecified;
-  inline constexpr unspecified values = unspecified;
+  inline constexpr auto keys = elements<0>;
+  inline constexpr auto values = elements<1>;
 }

[cjdb]

LGTM

[morinmorin]

@CaseyCarter, thanks for the suggestion. I should have asked you for the help before sending the issue to LWG.

I'll soon resend a modified one that replaces the old PR

 -3- `keys_view` is an alias for `elements_view<all_view<R>, 0>`…
 
+-?- The name `views::keys` denotes a range adaptor object (24.7.1). 
+For some subexpression `E`, the expression `views::keys(E)` is 
+expression-equivalent to `elements_view<all_view<decltype((E))>, 0>{E}`.
 
 -4- `values_view` is an alias for `elements_view<all_view<R>, 1>`…
 
+-?- The name `views::values` denotes a range adaptor object (24.7.1). 
+For some subexpression `E`, the expression `views::values(E)` is 
+expression-equivalent to `elements_view<all_view<decltype((E))>, 1>{E}`.

with the suggested PR.

[jensmaurer]

@morinmorin, do you have an LWG issue number for tracking?

[morinmorin]

@jensmaurer, I don't have an issue number yet. I'll post the number here, when I receive it. (I submitted another issue a day before submitting this to LWG, and that one got the number 3301 earlier today.)

[Dani-Hub]

A corresponding LWG issue has been created now: LWG 3302.

[JohelEGP]

Status: WP