Add constant_wrapper header with divide/multiply/increment and C++26 CMake support (P3663 piece 1 of N)

[Copilot]

First reviewable slice of PR #408. Establishes the constant_wrapper building block and consolidates compile-time arithmetic helpers in preparation for the P3663 submdspan canonicalization work.

CMake

• MDSPAN_CXX_STANDARD=26 with manual selection and auto-detection (prefers 26 > 23 > 20 > 17 > 14)
• MDSPAN_IMPL_ENABLE_P3663 option (default ON); propagated to all tests as a compile definition
• config.hpp default-defines MDSPAN_IMPL_ENABLE_P3663=1 for header-only / Kokkos-snapshot usage

constant_wrapper.hpp (new)

All symbols in MDSPAN_IMPL_STANDARD_NAMESPACE::detail. Two paths:

Condition	constant_wrapper / cw
__cpp_lib_constant_wrapper	using std::constant_wrapper; using std::cw;
otherwise	back-port aliasing detail::integral_constant<T, V>

Provides in both paths:

• increment(cw<V>) → cw<V+1> (compile-time)
• is_constant_wrapper<T> trait (handles const-qualified types from constexpr auto)
• divide<IndexT>(a, b) / multiply<IndexT>(a, b) — three overload tiers:
  1. Generic scalar (fall-through)
  2. std::integral_constant × std::integral_constant → detail::integral_constant (preserves compile-time value; divide short-circuits on zero numerator)
  3. constant_wrapper × constant_wrapper → cw<result> (C++26: returns std::constant_wrapper; back-port: returns detail::integral_constant)

using namespace Kokkos::detail;
constexpr auto c6 = cw<size_t(6)>;
constexpr auto c3 = cw<size_t(3)>;

static_assert(size_t(increment(c6)) == 7u);
static_assert(is_constant_wrapper<decltype(increment(c6))>);

static_assert(size_t(divide<size_t>(c6, c3)) == 2u);
static_assert(is_constant_wrapper<decltype(divide<size_t>(c6, c3))>);

static_assert(size_t(multiply<size_t>(c6, c3)) == 18u);
static_assert(is_constant_wrapper<decltype(multiply<size_t>(c6, c3))>);

submdspan_extents.hpp

• Removed divide and multiply definitions (now in constant_wrapper.hpp)
• Added #include "constant_wrapper.hpp"

Tests

test_constant_wrapper.cpp — registered unconditionally:

• IntegerPlus: basic construction, value access, and (under __cpp_lib_constant_wrapper) arithmetic with std::constant_wrapper
• Arithmetic: increment, divide (including zero-numerator), and multiply with size_t; verifies is_constant_wrapper holds for all results

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[crtrott]

The option should be IMPL only, and constant wrapper can be unconditionally there.

[Copilot]

The option should be IMPL only, and constant wrapper can be unconditionally there.

Done in 8cc9103. Renamed to MDSPAN_IMPL_ENABLE_P3663 throughout, and test_constant_wrapper is now registered unconditionally so constant_wrapper.hpp is always tested.

[crtrott]

The test added compile definition and the config change are not technically necessary in this PR but it's fine. Establishes for fellow up work the option. So leave it like it is.

[mhoemmen]

I've tested this with GCC trunk (16.0.1). It emits the warning but accepts the CMake option nevertheless.

[crtrott]

Move constant_wrapper to detail namespace.

[Copilot]

Move constant_wrapper to detail namespace.

Done in 48aa88c. constant_wrapper, cw, increment, and is_constant_wrapper are all now inside MDSPAN_IMPL_STANDARD_NAMESPACE::detail. The back-port path also simplifies to aliasing integral_constant directly (no full qualification needed since both live in detail).

[mhoemmen]

We shouldn't need to duplicate the definition, as it's the same on both sides -- unless you want the std::constant_wrapper side to use the overloaded arithmetic operators!

[mhoemmen]

The point of increment, divide, etc. is that we don't have to implement them twice. If they have exactly the same definitions on both sides, then it's just one definition that we can lift outside the macro branch.

[mhoemmen]

I know this is what the current code does, so I'm not complaining : - ) . Let me just think out loud for a bit.

The casting behavior here looks not consistent with the behavior for constant_wrapper or integral_constant, where the cast happens after the division instead of before. I want to reason through whether this should be of concern.

In the P3663 case, v0 and v1 should have already been canonicalized, that is, converted to index_type or constant_wrapper thereof. Thus, T0 (or T0::value_type), T1 (or T1::value_type), and IndexT should all be the same.

In the no-P3663 case, I'm guessing that T0 and T1 are any types convertible to index_type (the current implementation says "convertible to size_t" which isn't quite right). The arithmetic then happens after the conversion. That's needed if the input type isn't integral, but otherwise it's different behavior than the integral_constant overload. I don't think it's worth fixing this because the no-P3663 case is nonconforming anyway.