chore(c): Update to C++20

[fornwall]

Raise the C++ language standard for the whole ADBC C++ project (the c/ directory) from C++17 to C++20.

This also migrates from fmt to std::format.

Other changes using C++20 can come gradually over time once someone has a need for it.

• Compiler support matrix:
  • Compiler support for C++17
  • Compiler support for C++20
• A post from LLVM in November 2025:
  • RFC: Raise the minimum compiler requirements to move toward C++20
• Bumps in notable open source projects:
  • Qt — project agreed to raise its minimum required standard to C++20, dev mailing list May 2023: https://lists.qt-project.org/pipermail/development/2023-May/043893.html
  • Chromium — C++20 allowed in first-party code, November 2023: https://groups.google.com/a/chromium.org/g/chromium-dev/c/qjveLqape0I
  • Node.js 22 (V8 12.4) — build switched to requiring C++20, April 2024: https://nodejs.org/en/blog/release/v22.0.0
• What C++20 unlocks (concepts, ranges, coroutines, modules, designated initializers, consteval/constinit, the <=> spaceship operator, std::span, std::format, calendar/timezone <chrono>, etc):
  • https://en.cppreference.com/w/cpp/20
  • https://github.com/AnthonyCalandra/modern-cpp-features/blob/master/CPP20.md

[fornwall]

CI found some issues, will look at them. Meanwhile converted to draft. EDIT: Fixed by the fmt bump.

[lidavidm]

Sorry - while we can do this, I didn't necessarily want to. At the very least, since this will (IIRC) raise the manylinux target on wheels, I would want to announce in the next release that this is coming, and only after make the change.

[lidavidm]

Also, like, instead of upgrading {fmt} I'd rather get rid of it in favor of std::format (etc.)

[fornwall]

Sorry - while we can do this, I didn't necessarily want to

👍 Absolutely. Let me know if you think it makes sense to continue this PR, or if we should close it for now.

At the very least, since this will (IIRC) raise the manylinux target on wheels, I would want to announce in the next release that this is coming, and only after make the change.

It doesn't seem to raise the manylinux target - that will only happen by specific code causing references to new symbols (such as std::format on chrono types). There is an existing test here, so that does not slip by silently.

Also, like, instead of upgrading {fmt} I'd rather get rid of it in favor of std::format (etc.)

Let me know if you want to proceed with this C++20 update, and I can have a look at it!

[lidavidm]

It doesn't seem to raise the manylinux target - that will only happen by specific code causing references to new symbols (such as std::format on chrono types). There is an existing test here, so that does not slip by silently.

IIRC, the C++ compilers available on the manylinux2014 build image only have minimal C++20 support - so while an initial compile may work, there would be no point just raising the standard if we can't actually use it. And so I'd rather just hold off in that case.

[fornwall]

C++ compilers available on the manylinux2014 build image only have minimal C++20 support

Are we not using manylinux_2_28 here, which gets resolved to quay.io/pypa/manylinux_2_28:latest in the Dockerfile?

That seems (docker run quay.io/pypa/manylinux_2_28:latest gcc --version) to have a quite complete C++20 supporting toolchain (see New C++ features in GCC 14):

gcc (GCC) 14.2.1 20250110 (Red Hat 14.2.1-11)
gcc-toolset installed: gcc-toolset-14

Tried a simple concepts + ranges + std::format program, and it compiled and ran.

[lidavidm]

Oh, I forgot I had bumped it a while back...I thought we were still on 2014

[lidavidm]

Even so, I'd want to announce that we are doing this before we actually do it

[fornwall]

Even so, I'd want to announce that we are doing this before we actually do it

Absolutely, makes sense.

Let me know if I can help with anything (changes/investigation/communication).

[fornwall]

Pushed a (disclaimer: AI generated) migration from fmt to std::format:

• 4b19e92

[fornwall]

Migrating fmt -> std::format seems to require bumping macOS deployment target to 13.3:

• 500155c

If that is a blocker fmt could be kept around even on C++20 for now.

[fornwall]

The fmt -> std::format transition seems to require statically linking libstdc++ on ubuntu jammy (22.04):

• f55adf3

That is a unfortunate.. Let me know what you think about this PR:

1. Drop it for now.
2. Go for the C++20 transition, but not do the fmt -> std::format transition now (avoids statically linking with libstd++ on ubuntu 22.04).
3. Do both C++20 and fmt -> std::format, dropping support for ubuntu 22.04 (EOL: 2027-04).
4. Do both C++20 and fmt -> std::format, using a statically linked libstdc++ for jammy (current PR).