Proposed resolution:

This wording is relative to N4917.

1. Modify [memory.syn], header <memory> synopsis, as indicated:

   […]
   // [obj.lifetime], explicit lifetime management
   template<class T>
     T* start_lifetime_as(void* p) noexcept; // freestanding
   template<class T>
     const T* start_lifetime_as(const void* p) noexcept; // freestanding
   template<class T>
     volatile T* start_lifetime_as(volatile void* p) noexcept; // freestanding
   template<class T>
     const volatile T* start_lifetime_as(const volatile void* p) noexcept; // freestanding
   template<class T>
     T* start_lifetime_as_array(void* p, size_t n) noexcept; // freestanding
   template<class T>
     const T* start_lifetime_as_array(const void* p, size_t n) noexcept; // freestanding
   template<class T>
     volatile T* start_lifetime_as_array(volatile void* p, size_t n) noexcept; // freestanding
   template<class T>
     const volatile T* start_lifetime_as_array(const volatile void* p, size_t n) noexcept; // freestanding
   […]
   

2. Modify [ranges.syn], header <ranges> synopsis, as indicated:

   […]
   // [range.repeat], repeat view
   template<move_constructible W, semiregular Bound = unreachable_sentinel_t>
     requires (is_object_v<W> && same_as<W, remove_cv_t<W>>
       && (is-integer-like<Bound> || same_as<Bound, unreachable_sentinel_t>))
   class repeat_view; // freestanding
   
   namespace views { inline constexpr unspecified repeat = unspecified; } // freestanding
   […]
   // [range.stride], stride view
   template<input_range V>
     requires view<V>
   class stride_view; // freestanding
   
   template<class V>
     inline constexpr bool enable_borrowed_range<stride_view<V>> = enable_borrowed_range<V>; // freestanding
   
   namespace views { inline constexpr unspecified stride = unspecified; } // freestanding
   
   // [range.cartesian], cartesian product view
   template<input_range First, forward_range... Vs>
     requires (view<First> && ... && view<Vs>)
   class cartesian_product_view; // freestanding
   
   namespace views { inline constexpr unspecified cartesian_product = unspecified; } // freestanding
   […]
   

3. Modify [atomics.syn], header <atomic> synopsis, as indicated:

   namespace std {
     // [atomics.order], order and consistency
     enum class memory_order : unspecified; // freestanding
     inline constexpr memory_order memory_order_relaxed = memory_order::relaxed; // freestanding
     inline constexpr memory_order memory_order_consume = memory_order::consume; // freestanding
     inline constexpr memory_order memory_order_acquire = memory_order::acquire; // freestanding
     inline constexpr memory_order memory_order_release = memory_order::release; // freestanding
     inline constexpr memory_order memory_order_acq_rel = memory_order::acq_rel; // freestanding
     inline constexpr memory_order memory_order_seq_cst = memory_order::seq_cst; // freestanding
     […]
   }
   

[ 2022-11-12 Approved at November 2022 meeting in Kona. Status changed: Immediate → WP. ]

[ Kona 2022-11-07; Move to Immediate ]

This addresses the following NB comments:

• GB-085 ([memory.syn] start_lifetime_as and start_lifetime_as_array should be freestanding)

• GB-110 ([ranges.syn] New views should be freestanding (repeat, stride, cartesian_product))

• (partial) GB-130 ([atomics.syn] memory_order_acquire etc should be freestanding)

The explicit lifetime management functions requested by GB-085 have not been reviewed by LEWG in the context of freestanding, but they seem non-controversial in that context. None of the requested lifetime management functions run any code. I believe these were missed in post-merge conflict searches because the papers weren't targeted to LEWG or LWG at the time of those searches.

The ranges facilities requested by GB-110 have been reviewed on the LEWG mailing list in the context of freestanding. P1642R11 mentions the repeat, stride, and cartesian_product papers in "Potential Post-LEWG merge conflicts". All were discussed in an April 2022 reflector discussion and received six votes in favor of allowing these papers into freestanding, with no opposition.

The atomics facilities requested by GB-130 are essentially new names for existing facilities. Marking these as freestanding isn't concerning. There are concerns in GB-130 dealing with the specification details of freestanding enums, but those concerns won't be addressed in this issue.