Allow using C++20 as a fallback

[afbjorklund]

When I was bundling archivemount-ng for apptainer, I noticed that older distros* don't have a C++23 compiler...

But it seems that it would be relatively unintrusive to allow compiling as C++20 as well, so hopefully that is OK?

* el8, to be specific

g++ (GCC) 8.5.0 20210514 (Red Hat 8.5.0-28)

[fdegros]

The Makefile half of this is a nice, low-risk addition — CXXSTD ?= 23 plus using it in the -std=c++$(CXXSTD) / -std=gnu++$(CXXSTD) flags is a clean way to offer a compatibility knob. But the header changes in lib/hashed_string.h and lib/util.h are based on an incorrect premise, and I'd drop them.

The core claim doesn't hold up. The comments say bool operator()(const auto& a, const auto& b) const needs a C++20 fallback because it's a C++23 feature. It isn't — abbreviated function templates via auto parameters were standardized in C++20, not C++23. I checked this two ways:

1. A minimal repro fails under -std=c++17 and compiles clean under -std=c++20. GCC's own diagnostic under C++17 says: "use of 'auto' in parameter declaration only available with '-std=c++20'" — straight from the compiler, not from memory.
2. More conclusively: I syntax-checked every source file in this repo (lib/*.cc, fuse-archive.cc) under -std=c++20, completely unmodified, with full warnings on. All of them compile with zero errors, zero warnings.

So the three #if __cplusplus < 202302L / #else / #endif blocks here — each duplicating a one-line function body into a template version and an auto version — are solving a problem that doesn't exist. The original code already works identically under -std=c++20 with no changes needed.

Suggestion: keep just the Makefile change (CXXSTD ?= 23 and the two -std= substitutions), and drop the lib/hashed_string.h / lib/util.h changes entirely. That gets you a working CXXSTD=20 build today, with less code and no misleading comments about which standard introduced what.

If there's a different C++23-only feature elsewhere in the codebase that actually motivated this (rather than the auto-parameter syntax specifically), it'd be worth calling that out explicitly instead — but I couldn't find one by compiling the whole project under C++20.

[afbjorklund]

Thanks for the detailed investigation! I am happy also to throw C++20 under the bus, and skip all legacy compatbility.
Just that I did some similar hack when trying to compile archivemount-ng, since it was not plain C like archivemount.

        archivemount-ng)
            VER=${DIR/*-/}
            # Change from C++23 to C++20, in order to compile for Enterprise Linux 8
            sed -e 's/std=c++2b/std=c++2a/' -i Makefile
            # Substitute git operations with commands that work also from a tarball
            make VERSION="$VER" SOURCE_DATE_EPOCH=$(date +%s -r "archivemount.1.in")
            ;;

It doesn't even have real support, so it is using "2b" and "2a" instead of 23 and 20. Also, I need to install gcc-c++
I think I left C++ long before these new standards (like: Qt5?), recall struggling with C++11 and C++17 issues as well :-)

But let's go with making it a make variable! Hopefully it still works, as you mention.

Sorry for passing along the bad advice from the assistant, bad testing on my part...

Details

> I guess the original change should have been challenged and asked to verify claims

Yes, absolutely. The maintainer's response shows exactly how to verify: compile the entire codebase under the target standard without any modifications.

Key takeaway: When someone makes a claim about C++ feature availability, the proper response is to ask for verification via actual compilation, not take it at face value.

The original change incorrectly assumed auto parameters were C++23-only when they were actually C++20. The maintainer verified this by:

1. Checking that the code compiles cleanly under -std=c++20
2. Noting GCC's error message under C++17 confirms the feature is C++20+

In my case, I should have:

• Asked for the compilation test before accepting the header changes
• Or tested it myself with g++ -std=c++20 -c lib/hashed_string.h
• Or at minimum queried: "Have you verified this compiles under C++20 without modifications?"

The header changes added complexity (preprocessor conditionals, duplicated code) for a problem that didn't exist. Always verify before adding code.