This is an archive of the discontinued LLVM Phabricator instance.

[libc++] [ranges] ref_view and empty_view are borrowed ranges. Normalize borrowed_range tests.
ClosedPublic

Authored by Quuxplusone on Jan 25 2022, 10:03 AM.

Details

Summary

As reported in D116303. I've taken the liberty of simplifying all the existing borrowed_range tests to

  • be named borrowing.compile.pass.cpp
  • use simple library types, specifically empty_view (is borrowed) and single_view (is not borrowed), wherever possible (the only place this isn't possible AFAICT is in common_view, where I left a comment)
  • move range.ref.view into its own subdirectory, but not dig into that rabbit hole otherwise
  • consistently test for adherence to concept borrowed_range, rather than constexpr bool enable_borrowed_range — the latter is equally technically correct, but the former is shorter, and also more like what the library user will actually do in practice. No user should ever query enable_borrowed_range directly.

Diff Detail

Event Timeline

Quuxplusone requested review of this revision.Jan 25 2022, 10:03 AM
Quuxplusone created this revision.
Herald added a reviewer: Restricted Project. · View Herald TranscriptJan 25 2022, 10:03 AM
ldionne requested changes to this revision.Jan 25 2022, 12:19 PM

Instead of using single_view and empty_view to mean NonBorrowedRange and BorrowedRange, I would rather retain such "archetypes" in test_range.h and use them in our tests. That way, our tests won't be wrong if our implementation is, and their names is more telling than single_view and empty_view, which say nothing about their borrowable-ness. This would even be acceptable, but while we're at it why not define them self-standing:

using NonBorrowedRange = std::ranges::single_view;
using BorrowedRange = std::ranges::empty_view;

At least that documents what we're testing for free.

libcxx/test/std/ranges/range.adaptors/range.all/range.ref.view/borrowing.compile.pass.cpp
20–22
This revision now requires changes to proceed.Jan 25 2022, 12:19 PM
Quuxplusone marked an inline comment as done.Jan 25 2022, 1:19 PM

Instead of using single_view and empty_view to mean NonBorrowedRange and BorrowedRange, I would rather retain such "archetypes" in test_range.h and use them in our tests. That way, our tests won't be wrong if our implementation is, and their names is more telling than single_view and empty_view, which say nothing about their borrowable-ness. This would even be acceptable, but while we're at it why not define them self-standing:

using NonBorrowedRange = std::ranges::single_view;
using BorrowedRange = std::ranges::empty_view;

My resistance to this idea is the usual: "there's no such thing as an archetype." These tests do test the specific codepath devoted to borrowed ranges; but we shouldn't lose sight of the fact that the specific T we're instantiating them with has all the properties of single_view<T> or empty_view<T> — for example, it's a view itself, as opposed to a non-view. I actually just proposed a non-view BorrowedRange in one of @philnik's reviews! I suppose we could have our thing be named BorrowedView, and then have a BorrowedRange that's not a view, as well... Anyway, I'll pursue that a little bit, but at the moment I'm skeptical.
(Note that take_view<BorrowedView> is OK but take_view<BorrowedRange /*i.e. not a view*/> would be ill-formed.)

Add BorrowedRange, BorrowedView, and NonBorrowedView to "support/test_range.h". Ping @ldionne!

ldionne accepted this revision.Jan 27 2022, 8:32 AM
This revision is now accepted and ready to land.Jan 27 2022, 8:32 AM
This revision was landed with ongoing or failed builds.Jan 27 2022, 11:22 AM
This revision was automatically updated to reflect the committed changes.