C++20 baseline and C++26 readiness

Aner's required implementation language remains C++20 on Linux, macOS and Windows. The runtime, native compiler helpers and generated user programs do not require C++26. This development increment prepares evidence and implementation boundaries for later adoption; it does not enable a C++26 backend or change Aner's numerical or scientific contracts.

Most new C++26 syntax and library APIs cannot simply be used in a translation unit compiled as C++20. Newer compilers can still improve diagnostics, optimization and defect fixes while Aner uses C++20. Optional future C++26 components would need separate compilation, a stable boundary and a retained C++20 implementation. No such component is enabled in this increment.

Development cluster setup uses aner parallel native enroll for fresh private records and aner parallel native preflight for admission only checks through an approved compiled program. These commands retain C++20, strict host key checks and ABI/protocol identities; preflight runs no source level statements, scientific parameters or task callbacks. See native enrollment/preflight. Linux and Windows execution tests remain deferred.

What is implemented now

Normal targets and generated native programs request exact C++20 mode, with the existing strict floating point policy. A newer compiler's default language mode cannot silently change that policy.
Configuration compiles and links a C++20 baseline probe for the actual compiler, standard library and SDK: span, bit_cast, jthread/stop_token, atomic wait/notification, and atomic_ref. It runs again on each configure so an SDK replacement at the same path does not inherit an old cached success. This check does not execute a target binary during cross compilation.
aner --binary reports the active language mode, standard library identity/version, and raw standard feature test values. MSVC uses _MSVC_LANG, avoiding its legacy __cplusplus default. Future feature observations never activate a code path, select hardware, or establish full C++26 conformance.
A standalone portability project exercises the same baseline primitives and UTF-8 filesystem conversion without GPU, database, network or package manager dependencies. A verification only workflow prepares runs on Linux, both Mac architectures and Windows.
Portable CRT argument quoting fixtures cover spaces, embedded quotes, trailing backslashes, empty arguments, Unicode and embedded NUL rejection for Windows native compiler child launches. The native compiler and worker process adapters select the executable explicitly through CreateProcessW and preserve argument boundaries without a shell. The new Windows local worker backend adds protected pipes, inherited handle allowlists and Job Object ownership; its execution checks remain prepared and deferred at the user's request.
A C++20 UTF-8 filesystem helper replaces the four deprecated filesystem::u8path uses in data and manager I/O. It constructs paths from std::u8string; replacing these calls with a narrow path(std::string) would risk changing Windows filename interpretation. Unicode path round trips are checked by the standalone test. A literal UTF-8 versus universal character name assertion also checks source decoding; MSVC baseline and isolated probes use /utf-8, matching normal product targets.

The feature header is include/aner/cpp_features.hpp; filesystem conversion is include/aner/filesystem_path.hpp, and internal Windows argument quoting is include/aner/windows_arguments.hpp. They expose implementation observations and an internal conversion helper, not new Aner language APIs. Existing worker scheduling already uses C++20 jthread and stop tokens; native parallel execution does not have to wait for C++26 senders. Windows process cluster activation is limited to the compiled ANERNATIVE/2 route; older interpreter/session, ANERPAR/1 and neural/regression worker protocols retain explicit launch guards.

Read the actual build's evidence

aner --binary

The output includes the required C++20 baseline, actual language macro value and standard library. Library identifiers are raw vendor values: libc++ version, libstdc++ header date (__GLIBCXX__), or MSVC STL version/update; they are not interchangeable semantic version numbers. __cpp_lib_simd, __cpp_lib_inplace_vector, __cpp_lib_senders, __cpp_impl_reflection and __cpp_contracts are observations in the current compilation mode. Zero means the macro is not advertised there. A nonzero macro still needs the corresponding headers, compiled operation, supported target and semantic tests before an implementation is adopted. The older parallel algorithm macro __cpp_lib_execution is not used to infer sender support.

Run the dependency free C++20 checks from the source checkout:

cmake -S tools/cpp_readiness -B build/cpp-readiness
cmake --build build/cpp-readiness --config Release
ctest --test-dir build/cpp-readiness -C Release --output-on-failure

Optional compile/link observations for a separate future language probe project:

cmake -S tools/cpp_readiness -B build/cpp-future-probe -DANER_PROBE_FUTURE_CPP=ON
cmake --build build/cpp-future-probe --config Release
ctest --test-dir build/cpp-future-probe -C Release --output-on-failure

This standalone project tries an accepted -std=c++26/-std=c++2c flag, or MSVC /std:c++latest, only for isolated feature checks. The MSVC flag can include features beyond C++26. Each check requires its standard macro and a representative declaration/expression to compile and link. The result is written to future-readiness.txt; an absent feature or unsupported future flag is reported as unavailable/skipped. These observations do not change the runtime or generated program flags and do not execute experimental feature code. Do not add a global future standard flag to an Aner production build to perform this assessment.

Which features are worth adopting, and when

Candidate	Aner use and decision	Admission before use
`std::simd`	Candidate for selected CPU pointwise kernels. Existing optimized native loops and provider kernels remain useful in C++20. SIMD is not a cluster transport or a universal GPU interface.	A compatible implementation on each targeted compiler/library, actual ISA admission, strict policy numerical/bounds tests and representative measurements. Lane grouping must not silently reassociate reductions or change overflow/exception behavior.
`std::inplace_vector`	Candidate for genuinely bounded task/shape/protocol metadata where avoiding small allocations matters. It does not replace large numerical storage or global memory admission.	A demonstrated allocation/performance benefit, defined full capacity behavior, matching exception guarantees and a measured C++20 fallback. Keep it private to the implementation.
Execution senders/receivers	Candidate adapter behind the existing scheduler boundary after it solves a measured composition need. C++20 structured thread lifetimes and cancellation already support useful parallel work.	Verify ownership through completion, stop propagation, error ordering, admission limits and task joining. An API name or a successful `just(7)` probe does not validate a scheduler, GPU, SSH or cluster execution path.
Contracts	Potential redundant developer assertions. Aner's user visible checks remain explicit, located and enabled.	Contract checking modes and handlers must be understood on every build. A contract mode that ignores or merely observes a failed condition cannot replace units, bounds, overflow, resource or fit authorization checks.
Static reflection	Candidate for reducing internal metadata/registration maintenance, potentially in an isolated build tool. It does not implement Aner's own generic programming or scientific type checking.	Deterministic output, reviewed schema/source identity, reproducible generation and a stable generated representation. No compiler specific reflection type should enter public/native worker protocols.
C++23 facilities such as `expected` or `mdspan`	Evaluate separately when a concrete interface needs them. Their existence does not justify a C++26 migration.	Preserve ownership, checked access, source diagnostics and public ABI. Do not introduce optional standard library types into shared interfaces merely to reserve future names.

The first practical adoption is likely a small internal CPU kernel or bounded metadata container, selected by evidence rather than a date. An optional component could eventually be compiled in a newer mode while the core remains C++20, but only behind a reviewed primitive/opaque-handle boundary with explicit ownership and a working baseline implementation. Mixed standard standard library layouts, exceptions and compiler specific types are not a portable wire or plugin ABI.

A baseline wide change requires a separate decision after all supported OS/toolchain/SDK combinations, optional accelerator toolchains, deployed runtime dependencies and scientific regression suites pass. Supporting a flag on one developer machine is insufficient. CUDA/Metal, standard library runtime symbols and minimum OS deployment targets need their own compatibility evidence.

Protect semantics during a future transition

Keep integer arithmetic and conversions in Aner's checked helpers. Preserve strict/preserve/adapt policies and separate storage, arithmetic and accumulation precision. An internal SIMD implementation may not silently relax them. Numerical operation order, task identity, seed derivation, source locations and versioned wire formats remain Aner contracts regardless of the C++ standard used to implement them.

Keep scalar floating presentation in the existing explicit to_chars formatting path. C++ library changes to convenience formatting, including C++26 to_string behavior, must not silently change persisted identities or expected scientific output. Audit any formatting change separately. Units, row identity, provenance and model fit authorization continue to be enforced by Aner, rather than inferred from a new standard library type.

OS portability is also independent of language mode. The native build subcommand now recovers Windows wide command line arguments, converts them to checked UTF-8 paths, and launches the CMake/toolchain child through UTF 16 CreateProcessW with explicit CRT argument escaping. Generated projects use the SDK’s matching runtime configuration so MSVC Debug/Release runtime and iterator ABI settings are not mixed. The independent quoting/Unicode fixtures were exercised locally; actual Windows SDK compilation and process execution remain prepared checks, deferred at the user's request and not reported as a passed host test. This improvement covers native build, rather than claiming that every existing CLI command now has a wide argument entry point. The development source now implements Windows local compiled worker processes with restricted handle inheritance and kill on close Job Object cleanup. Windows coordinators can use the installed system OpenSSH client for enrolled POSIX commands or registered native SSH subsystems. Remote Windows enrollment uses an opaque service token and a reviewed byte transparent server launch contract; arbitrary client selected Windows shell commands remain outside this boundary. Protected configuration reads check ownership and effective ACLs on the same bounded file handle. A C++20 compile probe or a feature macro cannot establish process ownership, handle inheritance, cancellation or cleanup on another OS. Native cluster wire data must retain explicit fixed width encoding and a versioned scientific/ownership contract; never serialize a C++ container's object representation.

Current observations and limits

Local verification on October 24, 2026 used AppleClang 21.0.0.21000334 and libc++ 220106, with active C++20 language value 202002. The baseline compile/link check and executable primitive, Unicode path and Windows argument fixture checks pass on the local Mac. The quoting fixtures use golden cases and an independent decoder; they do not replace native Windows process tests. This toolchain accepts the separate -std=c++26 probe flag, but none of the five tested feature expressions compiles with its installed headers/default experimental feature settings. No C++26 feature was enabled in product code.

The prepared four platform workflow is verification infrastructure. Linux and Windows execution is deliberately deferred at the user's request; no remote workflow was executed in this unpublished run. Linux/GCC, Linux/Clang, Windows/MSVC, both Mac architectures, cross compiled binaries and optional provider configurations are not all validated by this local result. The existing four platform binary release workflow also builds the native helper/parallel/readiness tests and runs real source compilation tests, with native process/protocol checks prepared for each supported OS. This workflow was prepared but not run remotely here. No performance improvement is claimed from the readiness checks themselves.

Primary implementation references

Reviewed October 24, 2026. The vendor tables distinguish language and library support and continue to change; use the installed toolchain's probes before selecting a feature.

GCC language support and libstdc++ implementation status describe different parts of the toolchain. Availability of a language flag does not establish a useful standard library implementation.
Clang language status and libc++ C++26 status likewise track language/library work separately; an Apple toolchain is not interchangeable with the latest upstream LLVM release.
Apple's C++ support table includes Xcode/SDK availability and deployment considerations. MSVC conformance tracks support by Visual Studio version. Microsoft CRT argument parsing defines the quote/backslash boundary used by the internal process helper.
The standard draft's <version> description explains the implementation feature information used by the diagnostic header. Contracts P2900R14 describes multiple checking semantics; reflection P2996R13 describes a distinct language/library facility. Their publication does not itself establish the installed toolchain's support.