[libcxx-commits] [PATCH] D113161: [libc++] Implement P1989R2: range constructor for string_view
Arthur O'Dwyer via Phabricator via libcxx-commits
libcxx-commits at lists.llvm.org
Fri Nov 26 07:50:04 PST 2021
Quuxplusone added inline comments.
================
Comment at: libcxx/test/std/strings/string.view/string.view.cons/from_range.pass.cpp:60
+ DeletedStringViewConversionOperator d;
+ std::string_view csv = std::as_const(d);
+ assert(csv == "test");
----------------
Mordante wrote:
> jloser wrote:
> > Mordante wrote:
> > > Can you test whether it's !is_constructible, when the not used as const?
> > I think that's a bit tricky. For example,
> >
> > ```
> > static_assert(!std::is_constructible_v<std::string_view, decltype(d)>); // fails oddly enough
> > ```
> >
> > but
> > ```
> > std::string_view s = d; // hard error
> > assert(s == "test");
> > ```
> >
> > hard errors when trying to construct the `std::string_view` since it invokes the deleted implicit conversion operator:
> >
> > ```
> > libcxx/test/std/strings/string.view/string.view.cons/from_range.pass.cpp:66:20: error: conversion function from 'DeletedStringViewConversionOperator' to 'std::string_view' (aka 'basic_string_view<char>') invokes a deleted function
> > std::string_view s = d;
> > ```
> >
> > Did you have something specifically in mind that you think could work?
> Interesting, this is the test I expected to work...
I'm not sure I'm parsing either of your comments correctly, but yeah I would have expected it to be simple to add these lines to this test:
```
static_assert(!std::is_constructible_v<std::string_view, DeletedStringViewConversionOperator>);
static_assert(std::is_constructible_v<std::string_view, const DeletedStringViewConversionOperator>);
static_assert(std::is_constructible_v<std::string_view, DeletedConstStringViewConversionOperator>);
static_assert(!std::is_constructible_v<std::string_view, const DeletedConstStringViewConversionOperator>);
```
@jloser, are you saying that one of those lines gives a hard error? I don't //think// it should.
Also, naming nit: the words `StringView` aren't pulling their weight and could be omitted: `DeletedConversionOperator`, `DeletedConstConversionOperator`.
================
Comment at: libcxx/test/std/strings/string.view/string.view.cons/from_range.pass.cpp:44
+
+constexpr void test_deleted_string_view_conversion_operator() {
+ struct DeletedStringViewConversionOperator {
----------------
ldionne wrote:
> IMO, trying to encode what this test is doing in the function name is the worst of both worlds:
>
> 1. You can't use plain english to describe what the test really does in detail, and
> 2. The function name is long, which makes it really hard to read (especially when there are multiple long identifiers bunched together, I always end up having to re-read really slowly to figure out which one is being referred to -- here you have only one).
>
> IMO, this would be better, directly inside `test()` below:
>
> ```
> constexpr bool test() {
> test<char>();
> #ifndef TEST_HAS_NO_WIDE_CHARACTERS
> test<wchar_t>();
> #endif
> test<char8_t>();
> test<char16_t>();
> test<char32_t>();
>
> // Test that we're not trying to use the type's conversion operator to string_view in the constructor.
> {
> DeletedStringViewConversionOperator d;
> std::string_view csv = std::as_const(d);
> assert(csv == "test");
>
> DeletedConstStringViewConversionOperator dc;
> std::string_view sv = dc;
> assert(sv == "test");
> }
>
> return true;
> }
> ```
>
> Also, I think this would be slightly clearer, simply because we don't use `as_const` a lot in the test suite -- but I do find there's something nice to doing it your way (you could reuse the same variable for const and non-const tests if that was relevant):
>
> ```
> DeletedStringViewConversionOperator const d;
> std::string_view csv = d;
> assert(csv == "test");
> ```
>
> Finally, I would pin down the types of variables instead of using deduction guides, so I'd use `std::string_view<char> sv` instead of `std::string_view sv` -- this makes it obvious that any potential CTAD has nothing to do with what we're trying to test.
>
>
> Those are just suggestions, but the one about adding a comment instead of using a lengthy function name is something I'd love if you could address.
>
> I'd use `std::string_view<char> sv` instead of `std::string_view sv`
(Brain fart there: `string_view` is the non-template, `basic_string_view<char>` is the template. :))
================
Comment at: libcxx/test/std/strings/string.view/string.view.cons/from_range.pass.cpp:158
+ static_assert(test());
+ test_throwing(); // clang thinks data() member function is invalid constexpr due to use of throw, so we can't static_assert with this.
+
----------------
ldionne wrote:
> Clang is correct to not let you do this -- I think the comment adds very little information. WDYT?
+1.
================
Comment at: libcxx/test/std/strings/string.view/string.view.deduct/range.pass.cpp:24
constexpr void test() {
- auto val = MAKE_STRING_VIEW(CharT, "test");
- auto sv = std::basic_string_view(val.begin(), Sentinel(val.end()));
+ auto val = MAKE_STRING(CharT, "test");
+ auto sv = std::basic_string_view(val);
----------------
ldionne wrote:
> Can we add a test that exercises the deduction guide from a range that is *not* a `std::string`?
Something like this could do the trick:
```
#include "test_iterators.h"
struct Widget {
char16_t *data_ = u16"foo";
contiguous_iterator<const char16_t*> begin() const { return data_; }
contiguous_iterator<const char16_t*> end() const { return data_ + 3; }
};
basic_string_view bsv = Widget();
ASSERT_SAME_TYPE(decltype(bsv), std::basic_string_view<char16_t>);
```
================
Comment at: libcxx/test/std/strings/string.view/string.view.deduct/range.pass.cpp:43
int main(int, char**) {
test();
----------------
Is the lack of `static_assert(test());` here an accidental oversight? I see a lot of `constexpr` above that doesn't make sense otherwise.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D113161/new/
https://reviews.llvm.org/D113161
More information about the libcxx-commits
mailing list