Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[ranges] Should constexpr default_sentinel_t end() be const-qualified? #5507

Open
hewillk opened this issue Jun 5, 2022 · 4 comments
Open

[ranges] Should constexpr default_sentinel_t end() be const-qualified? #5507

hewillk opened this issue Jun 5, 2022 · 4 comments

Comments

@hewillk
Copy link
Contributor

hewillk commented Jun 5, 2022 •
edited

The begin/end of basic_istream_view is defined in [range.istream.view]

template<movable Val, class CharT, class Traits = char_traits<CharT>>
class basic_istream_view : public view_interface<basic_istream_view<Val, CharT, Traits>> {
public:
  constexpr auto begin() {
    *stream_ >> value_;
    return iterator{*this};
  }
  constexpr default_sentinel_t end() const noexcept;
};

Even if begin() is non-const-qualified, since end() simply returns default_sentinel, it is still designed to be const-qualified member function, which allows us to call as_const(r).end() even if as_const(r) is not a range.

However, the begin/end of chunk_view for input ranges is defined in [range.chunk.view.input] as

template<view V>
class chunk_view : public view_interface<chunk_view<V>> {
public:
  constexpr outer-iterator begin();
  constexpr default_sentinel_t end() noexcept;
};

Even though end() can be const-qualified, it is still designed to be non-const-qualified, which makes end()'s const-qualification consistent with begin()'s and prevents us from calling as_const(r).end().

Do we need to resolve this inconsistency?
@jensmaurer
Copy link
Member

This does not seem to be an issue that can be resolved editorially. Please file an LWG issue.

@jwakely
Copy link
Member

jwakely commented Jun 5, 2022

FWIW I think we did just make that change during the review of generator but I agree it would be non-editorial to change anything already in the working draft.

@hewillk
Copy link
Contributor Author

hewillk commented Jun 6, 2022

FWIW I think we did just make that change during the review of generator but I agree it would be non-editorial to change anything already in the working draft.

Thanks for your information.
So did the generator finally drop the const of end? What were the decision of the committee and the consideration behind it? It would be great to know.

@jwakely
Copy link
Member

jwakely commented Jun 6, 2022

Oh I got confused, end() was always const in the generator paper, but we added const to some other simple members that don't need to be non-const.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@jwakely @jensmaurer @hewillk