Introducing C++20, dropping C++11

[h-vetinari]

In the 2020 platform update there's the following statement:

Preparing for the Future

Of our supported platforms and compilers, the last to facilitate support for C++14 was Microsoft Visual C++ 2017, which was released on March 7, 2017. Therefore, Abseil will only support C++11 (and Microsoft Visual C++ 2015) until March 7, 2022. We will do one final Long Term Support release in March of 2022, at which point we will announce that it is the final LTS release to support C++11. We strongly recommend all users begin moving to C++14 or newer as soon as possible and not wait for this LTS release, however.

I'm encountering projects that are starting to need C++20 but still want to compile against abseil, which goes against abseil's expectation that:

Top-level application CMake projects should ensure a consistent C++ standard for all compiled sources by setting CMAKE_CXX_STANDARD.

Does abseil already switch anything based on C++20? Is it correct to assume for the time being that compiling abseil with C++20 is currently equivalent to C++17?

[derekmauro]

Does abseil already switch anything based on C++20? Is it correct to assume for the time being that compiling abseil with C++20 is currently equivalent to C++17?

I'm aware of at least one difference. The type returned by absl::bind_front is different in C++17 and C++20. I doubt this matters since code should be converting it to something like std::function at interface boundaries.

All of this is subject to change and assuming that C++17 mode is equivalent to C++20 mode might cause future breakages.

[h-vetinari]

Thanks for the context on this!

[h-vetinari]

Could you comment on why this issue should be closed already? Is there an updated timeline for either dropping C++11 and/or adding C++20?

[derekmauro]

I'm not sure what the issue is. I thought I answered your question. C++20 should be supported at this point. I'm not 100% sure when we will stop supporting C++11, but the statement you quoted says that you should not rely on it continuing much longer. Is there some other question I didn't answer?

[h-vetinari]

Just to be sure, I'm not complaining, I was just curious. AFAICT, there's no other publicly visible issue that tracks dropping C++11, and to be honest I wasn't sure about the status of C++20 either - it's great to hear that it's supported (as in: it compiles), but if it's actually a legitimate target cxx version for abseil now then I think that it should be documented as such...

Feel free to close this issue if you think these things are sufficiently tracked somewhere else or google-internally, but ceteris paribus, I'd close this at the earliest when C++11 is dropped.

[derekmauro]

This is now complete. As of 97ab3dc, building in C++11 mode is an error.

[pitrou]

@derekmauro 1) Is there a plan to document the various places in which the Abseil ABI differs between C++17 and C++20?

Also, 2) is there a plan to add a flag in options.h so that downstream packagers can force using the C++17 ABI? For now the absl::bind_front implementation doesn't seem to provide any such mechanism.

[h-vetinari]

Thanks @pitrou. This should probably be a new issue. IMO if the types are different (in an ABI relevant way), there should definitely be an option to enable/disable it, like all the others in absl/base/options.h.

[derekmauro]

@pitrou - Is there really code in the wild that is using the return type of absl::bind_front in its ABI?

[pitrou]

@derekmauro I have absolutely no idea!

[h-vetinari]

@pitrou - Is there really code in the wild that is using the return type of absl::bind_front in its ABI?

You should ask your colleague Hyrum. ;-)

Jokes aside, from the POV of integration, if differences can occur, they will, given enough projects & enough time. I'd really really prefer to be explicit on these differences, as abseil is already quite a handful to distribute (prebuilt, over an entire ecosystem) in a sane fashion.

[derekmauro]

You should ask your colleague Hyrum. ;-)

Jokes aside, from the POV of integration, if differences can occur, they will, given enough projects & enough time. I'd really really prefer to be explicit on these differences, as abseil is already quite a handful to distribute (prebuilt, over an entire ecosystem) in a sane fashion.

The return type of absl::bind_front and std::bind_front is deliberately unspecified. I would like to see an example of code that somehow managed to use the return type in its ABI where the correct answer isn't using std::function, absl::FunctionRef, or absl::AnyInvocable instead.

[h-vetinari]

where the correct answer isn't [...]

I think we have to face that people will more often than not use something "incorrect" that works for them. Such stuff creeps into projects everywhere eventually and I worry that merely having a difference we have no control over will not only come back to haunt us (=integrators) over time, but will usually be quite tricky to debug.

It's indeed possible that bind_front is so unrealistic to appear in anyone's ABI that it's fine to ignore, and you're the judge of that. But please understand our side where people spend hours debugging cryptic linker errors (sometimes not even coming from a direct dependency) that ultimately boil down to something like this.

The goal is not to put an undue burden on abseil, yet it's a very unusual situation that the ABI changes depending on which C++ version is used to compile. We have projects in our ecosystem that use anything from C++11 to C++20, and while not all of them will depend on abseil, all of them should in principle be co-installable, and in particular, projects depending on abseil might have (less divergent but still) different requirements e.g. some which require C++20 already vs. those that aren't even ready for C++17 yet.

[pitrou]

The return type of absl::bind_front and std::bind_front is deliberately unspecified. I would like to see an example of code that somehow managed to use the return type in its ABI where the correct answer isn't using std::function, absl::FunctionRef, or absl::AnyInvocable instead.

I don't have any real-world example to show, but decltype and auto would actually make this reasonably possible, wouldn't it?

[coryan]

Assuming C++ >= 17: https://godbolt.org/z/jhhWc8W7b

Of course there are other ways to write this code that does not depend on a stable ABI, but this is not perverse code either.