Breaking change: std::string_view usage in 8.8.0 breaks C++14 compatibility

[GerjandeGroot]

Version: 8.8.0
Regression from: 8.7.x (confirmed working)

std::string_view is a c++17 feature, meaning the changes in 8.8.0 break compatibility with c++14.

Questions for the maintainers:

• Was the C++14 compatibility drop intentional?
• If so, would this not be a reason to bump a mayor version?

[KevinEady]

Hi @GerjandeGroot ,

Our build requirements match those of Node.js, which IIRC is C++17 in Node.js v22.

[BYVoid]

Independently reproduced on 8.8.0 while building an addon with -std=c++14. Two things that may help narrow the fix:

1. It's not only std::string_view — if constexpr is also used (C++17).
Even if the string_view overloads were guarded, the header still won't compile as C++14 because of if constexpr in the ObjectWrap finalizer path:

• napi-inl.h:1379, 1426 — std::string_view (Symbol::New)
• napi-inl.h:1267 — String::New(env, val.data(), val.size()) (follows from the string_view overload)
• napi-inl.h:5338, 5348 — if constexpr (details::HasBasicFinalizer<T>::value) / HasExtendedFinalizer

So restoring C++14 support would require guarding both constructs, not just string_view.

2. Clang masks the regression; GCC does not.
With GCC 16 at -std=c++14 it's a hard error:

napi-inl.h:1379:46: error: 'std::string_view' has not been declared
   note: 'std::string_view' is only available from C++17 onwards

With Clang + libc++ at -std=c++14 the same code only produces warnings ('std::string_view' ... C++17, -Wc++17-extensions for if constexpr) and compiles successfully. CI that builds only with Clang/libc++ will not catch this — which is likely how it shipped in 8.8.0.

3. For the record — where the "C++14" baseline actually comes from.
node-addon-api itself doesn't document a minimum C++ standard. I grepped the whole repo (docs, *.gyp/*.gypi, CMake) and there is no stated baseline anywhere — the only cplusplus hits are links to cppreference. The C++14 expectation comes from Node's bundled common.gypi (the one node-gyp includes when compiling an addon), not from any node-addon-api doc:

Node	default -std in common.gypi
14	gnu++1y (C++14 draft)
16	gnu++14
18 / 20 / 22	gnu++17
24	gnu++20

So default node-gyp builds on currently-supported Node (18+) are already ≥C++17 and unaffected. The breakage surfaces for (a) builds that explicitly set -std=c++14 (this issue, plus non-node-gyp build systems like CMake/Bazel that pick the standard themselves), and (b) older/EOL Node toolchains (≤16). Given that, it would help to document node-addon-api's actual minimum standard (now effectively C++17) rather than leave it implicit — and ideally add a -std=c++14 GCC build in CI to prevent silent regressions like this.