Enhancement: libc++ provides string_view for all C++ language levels about abseil-cpp

[JonathanDCohen]

Sorry for the silence on this. I'm slightly wary about this because a couple reasons

First, some of the people working on migrating google3 to c++17 have expressed some slight misgivings about it. Second, because, even though we don't really support it, this is potentially a break for use of abseil functions with ADL for a change which is, ideally otherwise invisible to the user and adds a corner case to the story of Abseil's handling of c++ versions. I agree with your sentiment that this is more an extension than some kind of non-conforming break, but seeing that string_view is a fairly simple type, I'm not sure the small risk is worth the payoff for this. But I'm definitely open to being convinced.

[atkawa7]

@mclow @derekmauro @rogeeff Should be careful about __has_include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79433
https://bugs.chromium.org/p/chromium/issues/detail?id=759349&desc=2

[zhangxy988]

@atkawa7 IIRC, the bug is about using libstdc++ with -std=<version older than c++17>. Since we are also checking __cplusplus >= 201703L, the bug should NOT be a concern.

[atkawa7]

@zhangxy988 See google/crc32c@d0f929a

[zhangxy988]

@atkawa7 The commit seems strange to me: the bug in the original code is in #if !defined(_MSC_VER) || __cplusplus >= 201703L which is ignoring the __cplusplus >= 201703L check on any non MSVC compiler (GCC, Clang), and this should be fixed as #if !defined(_MSC_VER) && __cpluscplus >= 201703L (or simply #if __cplusplus >= 201703L since _MSC_VER set __cpluscplus to 199711).
So, I don't think this has anything to do with the GCC bug.

[atkawa7]

@zhangxy988 They are two different bugs but similar. So should be careful

[JonathanDCohen]

This is really about libc++, yes? So really we just want to check for libc++, and handle the msvc and libstdc++ cases separately.

According to this stackoverflow we can do this by something like

#include <ciso646>
// ...
#ifdef _LIBCPP_VERSION
#define ABSL_HAVE_STD_STRING_VIEW 1
#else 
// ...

@mclow is this a reasonable idea?

[mclow]

Almost - you still have to check for the existence of the <string_view> header. Old versions of libc++ didn't have this. but if the header is there, then you have string_view

[EricWF]

@mclow @JonathanDCohen Alternatively (if you don't have __has_include, but you should), you could probably check that _LIBCPP_VERSION >= 4000.

[mclow]

Maybe if you don't have __has_include maybe you should just fail (and say "no std::string_view)

[JonathanDCohen]

Sorry for the silence here. I've had this sitting around internally for a bit, and there's some concern that libc++ backporting string_view is technically non-conforming, and could be surprising w.r.t. ADL. We also have to take a look at our FDO profiles before landing this as this would potentially change the mangled symbol names for anything taking a string_view

[mclow]

I think that "non-conforming" is a bit harsh. It's an extension, like marking the default constructor of vector as noexcept.

[JonathanDCohen]

After some more discussions on this, I'm going to close this issue. It's tempting but there are other internal migration factors which this seems to complicate, and the payoff for it is fairly low. Thank you for the idea, though :) Please feel free to re-open if you feel this is a poor decision.

[mclow]

but there are other internal migration factors which this seems to complicate, and the payoff for it is fairly low.

Those are pretty hard for me to comment on (not being internal).

Please feel free to re-open if you feel this is a poor decision.

I'm not going to contest.