LWG3679 Is <ranges> sufficient for istream_view?

[jwakely]

LWG and SG9 would like LEWG to decide on a direction for this issue:

https://wg21.link/lwg3679

We see four options:

• Put istream_view in new header so that <ranges> doesn't need <istream>
• Pay the cost of including <istream> in <ranges>.
• Make things ill-formed if the header isn't included (with informative diagnostic if possible?)
• Accept status quo (with work-around): need to include both headers.

Kona minutes

[dietmarkuehl]

We discussed LWG3679 in LWG. The issue is that istream_view is in
<ranges> and requires inclusion of <istream> which is in general
undesirable: the user implementation with current implementation
is bad when the user didn't include <istream>. We came to the
conclusion that there are some design alternatives on which we think
LEWG may form an opinion.

We came up with 4 potential approaches (there may be more) to address
the problem:

1. Pay the cost: The standard could mandate that istream_view needs
   to work with a user merely including <ranges>. That would
   effectively mandate that implementation need to include major
   parts of <istream> which tends to slow down compilation
   significantly. Analysis shows that there is a slow-down at
   compile-time for translation units which don't include the
   header already but it isn't huge, even on an otherwise empty
   translation unit.
2. Status quo: Have the compilation fail in some form if istream_view
   is used without including <istream>. The error message can
   probably be improved over the current form to more directly
   point at the problem, e.g., by using a static_assert detecting
   whether <istream> was included by detecting some hidden
   declaration or detecing whether
   std::declval<std::istream&>() >> std::declval<int&> works.
3. Ill-Formed: make the use of istream_view ill-formed in case
   <istream> isn't inlcuded.
4. New header: Use a new header, like <stream_views> declaring
   istream_view and possibly other stream-related views needing
   <istream> or <ostream>. This approach is fairly straight
   forward to implement and the cost is only paid when explicitly
   requested.

Once we know which direction is preferable a corresponding resolution
for the issue can be drafted.

[mclow]

@dietmarkuehl All the header names disappeared in your comment.

The standard could mandate that istream_view needs to work with a user merely including .

[jwakely]

@dietmarkuehl All the header names disappeared in your comment.

Fixed

[brycelelbach]

2023-01-10 Library Evolution Telecon

LWG3679: Is <ranges> sufficient for istream_view?

2023-01-10 Library Evolution Telecon Minutes

Champion: Tim Song

Chair: Bryce Adelstein Lelbach

Minute Taker: Ben Craig

Start: 2023-01-10 11:37 Eastern

Does fixing this mean we have to make <ranges> include <istream>?

Options:

1. Pay the cost and make it work
2. Status quo
3. Ill-formed
4. New header

POLL: Make istream_view work when a user includes only <ranges>.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
0	0	0	7	2

Attendance: 16

# of Authors: 0

Author Position: N/A

Outcome: Unanimous consensus against.

POLL: Make it ill-formed to use istream_view when only including <ranges>.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
0	5	4	0	0

Attendance: 14

# of Authors: 0

Author Position: N/A

Outcome: No consensus, but we'd entertain a paper.

End: 11:54

Summary

This issue points out that its unclear whether istream_view is usable when only including <ranges>. We discussed 4 possible options:

1. Pay the cost and make it work, which there was opposition to.
2. Status quo, which we seemed to be okay with.
3. Ill-formed, which we seemed to be okay with.
4. New header, which was only briefly discussed, and didn't seem to have much support.

Next Steps

We'd need a paper exploring how to make istream_view ill-formed when only including <ranges> to move forward.