WG21-P2833R2 Freestanding Library: inout expected span
Feature-test macros (expected):
#define __cpp_lib_freestanding_expected 202311L
#define __cpp_lib_freestanding_mdspan 202311L
INCREASED feature-test macro (expected):
#define __cpp_lib_out_ptr 202311L
INCREASED feature-test macro (expected); note that WG21-P2821R5 #4176 is intentionally simultaneously updating this value:
#define __cpp_lib_span 202311L
This paper is vaguely similar to #4172, but seems more complicated. Again, we're not entirely sure what our hosted implementation needs to do here. IF all we need to do is define the __cpp_lib_freestanding_MEOW macros and increase __cpp_lib_out_ptr, then we could accept a PR for that before we open up the floodgates to arbitrary C++26 features. However, because WG21 made both this paper and WG21-P2821R5 #4176 simultaneously update __cpp_lib_span, and that paper is an actual C++26 feature, we should not increase that macro's value for this paper.
WG21-P2833R2 Freestanding Library:
inoutexpectedspanFeature-test macros (expected):
INCREASED feature-test macro (expected):
INCREASED feature-test macro (expected); note that WG21-P2821R5 #4176 is intentionally simultaneously updating this value:
This paper is vaguely similar to #4172, but seems more complicated. Again, we're not entirely sure what our hosted implementation needs to do here. IF all we need to do is define the
__cpp_lib_freestanding_MEOWmacros and increase__cpp_lib_out_ptr, then we could accept a PR for that before we open up the floodgates to arbitrary C++26 features. However, because WG21 made both this paper and WG21-P2821R5 #4176 simultaneously update__cpp_lib_span, and that paper is an actual C++26 feature, we should not increase that macro's value for this paper.