WIP: Consider C++17 string_view

[GregBowyer]

This is more a WIP and discussion for design.

Cxx looks great but I think there are some things we can consider or use regarding absl (unlikely unless we add options or sub crates for customization) and the standard.

A few things that pop out would be span types and string_view

How do we discover CXX features?

In the WIP PR I threw together (sorry was quick to get a discussion), I stole the absl detection code for figuring out if string_view exists in the compilation environment, and if so uses that instead of const char* / std::string as the constructor for ::Str. string_view is compatible with both callings of the constructor and has very similar semantics to ::Str and the internal representation.

Naturally for a none C++17 and onwards environment I figure we drop back to what is already there, or maybe suggest the use of absl as a bridging library.

Do we have any thoughts here, if wanted we could add in a few bridiging types that are forthcoming in newer versions of c++

[dtolnay]

Hi @GregBowyer, thanks for the suggestion. I am open to doing this sort of feature detection for standard library headers from more recent standards.

One thing that would remain to figure out is what to do instead of cxx/build.rs#L4, which currently unconditionally build the bundled c++ library in c++11 mode.

[GregBowyer]

Heh for me I am using bazel so ... thats not a problem

But yes that also should be figured out ... maybe the dreaded cargo features?

[dtolnay]

How about setting up some Cargo features to opt in to bindings beyond the basic set? Downstream could enable them as:

# Cargo.toml

[dependencies]
cxx = { version = "0.2", features = ["c++17", "absl"] }

[adetaylor]

There's a comment here with more thoughts about feature detection - #117 (comment)

[roligugus]

Just wondering about the status of this @GregBowyer .

I will be working on adding folly::ByteRange/StringPiece conversions to cxx for our internal usage. Adding string_view and eventually span for slices/Vec kinda fits into that as well - separate tickets though. Abseil support would be similar to folly.

I'd propose both absl and folly as additional APIs to the string_view ones. This allows for modernization in our code base where we will replace e.g. folly::StringPiece with std::string_view in the future. Having both string_view and folly APIs will allow us to do that progressively.

Like your switch in the ctors to string_view. Would propose the also add the explicit cast operators to cover the other direction as well.