Revised 2025-09-17 at 14:48:18 UTC

Tentative Issues

3908(i). enumerate_view::iterator constructor is explicit

Section: 25.7.24.3 [range.enumerate.iterator] Status: Tentatively NAD Submitter: Jonathan Wakely Opened: 2023-03-23 Last modified: 2024-06-24

Priority: Not Prioritized

View other active issues in [range.enumerate.iterator].

View all other issues in [range.enumerate.iterator].

View all issues with Tentatively NAD status.

Discussion:

enumerate_view::iterator has this constructor: 

    constexpr explicit
      iterator(iterator_t<Base> current, difference_type pos);  // exposition only

In P2164R9 the detailed description of the function showed a default argument for the second parameter, which would justify it being explicit. However, that default argument was not present in the class synopsis and was removed from the detailed description when applying the paper to the draft.

[2023-06-01; Reflector poll]

Set status to Tentatively NAD after four votes in favour during reflector poll. The constructor is exposition-only, it doesn't make any difference to anything whether it's explicit or not.

Proposed resolution:

This wording is relative to N4944.

  1. Modify the class synopsis in 25.7.24.3 [range.enumerate.iterator] as shown: 

    
    constexpr explicit
      iterator(iterator_t<Base> current, difference_type pos);  // exposition only

  2. Modify the detailed description in 25.7.24.3 [range.enumerate.iterator] as shown: 

      constexpr explicit iterator(iterator_t<Base> current, difference_type pos);

    -2- Effects: Initializes current_ with std::move(current) and pos_ with pos.

3909(i). Issues about viewable_range

Section: 99 [ranges.refinements], 25.7.2 [range.adaptor.object] Status: Tentatively NAD Submitter: Jiang An Opened: 2023-03-27 Last modified: 2023-06-01

Priority: Not Prioritized

View all issues with Tentatively NAD status.

Discussion:

After LWG 3724(i), views::all is well-constrained for view types, and the constraints are stronger than viewable_range. The difference is that given an expression such that decltype gives R, when decay_t<R> is a view type and the implicit conversion of R to decay_t<R> is forbidden, views::all rejects the expression, but viewable_range may accept R. So I think we should remove the additional constraints on views::all_t.

While viewable_range is probably not introducing any additional constraint within the standard library, I think it is still useful to express the constraints on views::all, so it should be slightly adjusted to match views::all.

Furthermore, viewable_range is currently used in 25.7.2 [range.adaptor.object], but given P2378R3 relaxed the requirements for range adaptor closure objects, I think we should also apply similar relaxation for range adaptor objects. This should have no impact on standard range adaptor objects.

[2023-06-01; Reflector poll]

Set status to Tentatively NAD after three votes in favour during reflector poll.

"First change is pointless. Second change is a duplicate of 3896(i). Range adaptors return a view over their first argument, so they need to require it's a viewable_range."

Proposed resolution:

This wording is relative to N4944.

  1. Change the definition of views::all_t in 25.2 [ranges.syn] as indicated: 

    
   template<viewable_rangeclass R>
      using all_t = decltype(all(declval<R>()));          // freestanding

  2. Change the definition of viewable_range in 25.4.6 [range.refinements] as indicated:

    -6- The viewable_range concept specifies the requirements of a range type that can be converted to a view safely. 

    
template<class T>
  concept viewable_range =
    range<T> &&
    ((view<remove_cvref_t<T>> && constructible_from<remove_cvref_t<T>, T> convertible_to<T, remove_cvref_t<T>>) ||
     (!view<remove_cvref_t<T>> &&
      (is_lvalue_reference_v<T> || (movable<remove_reference_t<T>> && !is-initializer-list<T>))));

  3. Change 25.7.2 [range.adaptor.object] as indicated:

    -6- A range adaptor object is a customization point object (16.3.3.3.5 [customization.point.object]) that accepts a viewable_rangerange as its first argument and returns a view.

    […]

    -8- If a range adaptor object adaptor accepts more than one argument, then let range be an expression such that decltype((range)) models viewable_rangerange, let args... be arguments such that adaptor(range, args...) is a well-formed expression as specified in the rest of subclause 25.7 [range.adaptors], and let BoundArgs be a pack that denotes decay_t<decltype((args))>.... The expression adaptor(args...) produces a range adaptor closure object f that is a perfect forwarding call wrapper (22.10.4 [func.require]) with the following properties: [...]

3958(i). ranges::to should prioritize the "reserve" branch

Section: 25.5.7.2 [range.utility.conv.to] Status: Tentatively NAD Submitter: Hewill Kang Opened: 2023-07-17 Last modified: 2024-01-29

Priority: Not Prioritized

View other active issues in [range.utility.conv.to].

View all other issues in [range.utility.conv.to].

View all issues with Tentatively NAD status.

Discussion:

When the constructed range object has no range version constructor, ranges::to falls into a branch designed specifically for C++17-compliant containers, which calls the legacy constructor that accepts an iterator pair with C(ranges::begin(r), ranges::end(r), std::forward<Args>(args)...).

However, this kind of initialization may bring some performance issues, because we split the original range into pairs of iterators, which may lose information contained in the original range, for example: 

#include <boost/container/vector.hpp>
#include <sstream>
#include <ranges>

int main() {
  std::istringstream ints("1 2 3 4 5");
  std::ranges::subrange s(std::istream_iterator<int>(ints),
                          std::istream_iterator<int>(),
                          5);
  auto r = std::ranges::to<boost::container::vector>(s); // discard size info
}

Above, subrange saves the size information of the stream, but ranges::to only extracts its iterator pair to create the object, so that the original size information is discarded, resulting in unnecessary allocations.

I believe we should prefer to use the "reserve" branch here because it is really designed for this situation.

[2023-10-30; Reflector poll]

Set status to Tentatively NAD after reflector poll. "This optimizes exotic cases at the expense of realistic cases."

Proposed resolution:

This wording is relative to N4950.

  1. Modify 25.5.7.2 [range.utility.conv.to] as indicated:

    template<class C, input_range R, class... Args> requires (!view<C>)
  constexpr C to(R&& r, Args&&... args);

    -1- Mandates: C is a cv-unqualified class type.

    -2- Returns: An object of type C constructed from the elements of r in the following manner:

    1. (2.1) — If C does not satisfy input_range or convertible_to<range_reference_t<R>, range_value_t<C>> is true:

      1. (2.1.1) — If constructible_from<C, R, Args...> is true:

        C(std::forward<R>(r), std::forward<Args>(args)...)

      2. (2.1.2) — Otherwise, if constructible_from<C, from_range_t, R, Args...> is true:

        C(from_range, std::forward<R>(r), std::forward<Args>(args)...)

      3. (2.1.3) — Otherwise, if

        1. (2.1.3.1) — common_range<R> is true,

        2. (2.1.3.2) — the qualified-id iterator_traits<iterator_t<R>>::iterator_category is valid and denotes a type that models derived_from<input_iterator_tag>, and

        3. (2.1.3.3) — constructible_from<C, iterator_t<R>, sentinel_t<R>, Args...> is true:

          C(ranges::begin(r), ranges::end(r), std::forward<Args>(args)...)

      4. (2.1.4) — Otherwise, if

        1. (2.1.4.1) — constructible_from<C, Args...> is true, and

        2. (2.1.4.2) — container-insertable<C, range_reference_t<R>> is true:

          C c(std::forward<Args>(args)...);
if constexpr (sized_range<R> && reservable-container<C>)
  c.reserve(static_cast<range_size_t<C>>(ranges::size(r)));
ranges::copy(r, container-inserter<range_reference_t<R>>(c));

      5. (?.?.?) — Otherwise, if

        1. (?.?.?.?) — common_range<R> is true,

        2. (?.?.?.?) — the qualified-id iterator_traits<iterator_t<R>>::iterator_category is valid and denotes a type that models derived_from<input_iterator_tag>, and

        3. (?.?.?.?) — constructible_from<C, iterator_t<R>, sentinel_t<R>, Args...> is true:

          C(ranges::begin(r), ranges::end(r), std::forward<Args>(args)...)

    2. (2.2) — Otherwise, if input_range<range_reference_t<R>> is true:

      to<C>(r | views::transform([](auto&& elem) {
  return to<range_value_t<C>>(std::forward<decltype(elem)>(elem));
}), std::forward<Args>(args)...);

    3. (2.3) — Otherwise, the program is ill-formed.

3980(i). The read exclusive ownership of an atomic read-modify-write operation and whether its read and write are two operations are unclear

Section: 32.5.4 [atomics.order] Status: Tentatively NAD Submitter: jim x Opened: 2023-08-22 Last modified: 2023-11-03

Priority: Not Prioritized

View other active issues in [atomics.order].

View all other issues in [atomics.order].

View all issues with Tentatively NAD status.

Discussion:

Such two questions are sourced from StackOverflow:

  1. Can the read operations in compare_exchange_strong in different two thread read the same value?

  2. For purposes of ordering, is atomic read-modify-write one operation or two?

Given this example: 

#include <iostream>
#include <atomic>
#include <thread>

struct SpinLock{
  std::atomic<bool> atomic_;
  void lock(){
    bool expected = false;
    while (!atomic_.compare_exchange_strong(expected,true,std::memory_order_release,std::memory_order_relaxed)) {
    }
  }
  void unlock(){
    atomic_.store(false, std::memory_order_release);
  }
};

int main(){
  SpinLock spin{false};
  auto t1 = std::thread([&](){
    spin.lock();
    spin.unlock();
  });
  auto t2 = std::thread([&](){
    spin.lock();
    spin.unlock();
  });
  t1.join();
  t2.join();
}

In the current draft, the relevant phrasing that can interpret that only one read-modify-write operation reads the initial value false is 32.5.4 [atomics.order] p10:

Atomic read-modify-write operations shall always read the last value (in the modification order) written before the write associated with the read-modify-write operation.

However, the wording can have two meanings, each kind of read can result in different explanations for the example

  1. The check of the violation is done before the side effect of the RMW is in the modification order, i.e. the rule is just checked at the read point.

  2. The check of the violation is done after the side effect of the RMW is in the modification order, i.e. the rule is checked when RMW tries to add the side effect that is based on the read-value to the modification order, and that side effect wouldn't be added to the modification order if the rule was violated.

With the first interpretation, the two RMW operations can read the same initial value because that value is indeed the last value in the modification order before such two RMW operations produce the side effect to the modification order.

With the second interpretation, there is only one RMW operation that can read the initial value because the latter one in the modification order would violate the rule if it read the initial value.

Such two interpretations arise from that the wording doesn't clearly specify when that check is performed.

So, my proposed wording is:

Atomic read-modify-write operations shall always read the value from a side effect X, where X immediately precedes the side effect of the read-modify-write operation in the modification order.

This wording keeps a similar utterance to 6.10.2.2 [intro.races], and it can clearly convey the meaning that we say the value read by RWM is associated with the side effect of RMW in the modification order.

Relevant discussion can be seen CWG/issues/423 here.

[2023-11-03; Reflector poll]

NAD. The first reading isn't plausible.

Proposed resolution:

This wording is relative to N4958.

  1. Modify 32.5.4 [atomics.order] as indicated:

    -10- Atomic read-modify-write operations shall always read the last value from a side effect X, where X immediately precedes the side effect of the read-modify-write operation (in the modification order) written before the write associated with the read-modify-write operation.

    -11- Implementations should make atomic stores visible to atomic loads within a reasonable amount of time.

3981(i). Range adaptor closure object is underspecified for its return type

Section: 25.7.2 [range.adaptor.object] Status: Tentatively NAD Submitter: Hewill Kang Opened: 2023-08-22 Last modified: 2024-06-24

Priority: Not Prioritized

View other active issues in [range.adaptor.object].

View all other issues in [range.adaptor.object].

View all issues with Tentatively NAD status.

Discussion:

In order to provide pipe support for user-defined range adaptors, P2387R3 removed the specification that the adaptor closure object returns a view, which conforms to the wording of ranges::to.

However, the current wording seems to be too low-spec so that the range adaptor closure object can return any type or even void. This makes it possible to break the previous specification when returning types that don't make sense, for example: 

#include <ranges>

struct Closure : std::ranges::range_adaptor_closure<Closure> {
  struct NonCopyable {
    NonCopyable(const NonCopyable&) = delete;
  };

  const NonCopyable& operator()(std::ranges::range auto&&);
};

auto r = std::views::iota(0) | Closure{}; // hard error in libstdc++ and MSVC-STL

Above, since the return type of the pipeline operator is declared as auto, this causes the deleted copy constructor to be invoked in the function body and produces a hard error.

The proposed resolution adds a specification for the range adaptor closure object to return a cv-unqualified class type.

[2023-10-30; Reflector poll]

Set status to Tentatively NAD. "The wording says R | C is equivalent to C(R), not auto(C(R))."

Proposed resolution:

This wording is relative to N4958.

  1. Modify 25.7.2 [range.adaptor.object] as indicated:

    -1- A range adaptor closure object is a unary function object that accepts a range argument. For a range adaptor closure object C and an expression R such that decltype((R)) models range, the following expressions are equivalent:

    […]

    -2- Given an object t of type T, where

    1. (2.1) — t is a unary function object that accepts a range argument and returns a cv-unqualified class object,

    2. […]

    then the implementation ensures that t is a range adaptor closure object.

3982(i). is-derived-from-view-interface should require that T is derived from view_interface<T>

Section: 25.4.5 [range.view] Status: Tentatively NAD Submitter: Hewill Kang Opened: 2023-08-22 Last modified: 2023-10-30

Priority: Not Prioritized

View all other issues in [range.view].

View all issues with Tentatively NAD status.

Discussion:

Currently, the wording of is-derived-from-view-interface only detects whether type T is unambiguously derived from one base class view_interface<U> where U is not required to be T, which is not the intention of CRTP.

[2023-10-30; Reflector poll]

Set status to Tentatively NAD. The wording correctly handles the case where T derives from Base which derives from view_interface<Base>. We don't want it to only be satisfied for direct inheritance from view_interface<T>, but from any specialization of view_interface. Previously the concept only checked for inheritance from view_base but it was changed when view_interface stopped inheriting from view_base.

Proposed resolution:

This wording is relative to N4958.

  1. Modify 25.4.5 [range.view] as indicated:

    template<class T>
  constexpr bool is-derived-from-view-interface = see below;            // exposition only
template<class T>
  constexpr bool enable_view =
    derived_from<T, view_base> || is-derived-from-view-interface<T>;

    -6- For a type T, is-derived-from-view-interface<T> is true if and only if T has exactly one public base class view_interface<TU> for some type U and T has no base classes of type view_interface<UV> for any other type UV.

4003(i). view_interface::back is overconstrained

Section: 25.5.3 [view.interface] Status: Tentatively NAD Submitter: Hewill Kang Opened: 2023-10-28 Last modified: 2024-06-24

Priority: Not Prioritized

View all other issues in [view.interface].

View all issues with Tentatively NAD status.

Discussion:

Currently, view_interface only provides the back member when the derived class satisfies both bidirectional_range and common_range, which ensures that ranges::prev can act its sentinel.

However, requiring common_range seems to be too strict because when the derived class satisfies both random_access_range and sized_range, its end iterator can still be calculated in constant time, which is what some range adaptors currently do to greedily become common ranges.

I think we should follow similar rules to eliminate this inconsistency (demo): 

#include <ranges>

constexpr auto r = std::ranges::subrange(std::views::iota(0), 5);
constexpr auto z = std::views::zip(r);
static_assert(r.back() == 4); // ill-formed
static_assert(std::get<0>(z.back()) == 4); // ok

[2023-11-07; Reflector poll]

NAD. "During the concat discussion LEWG decided not to support the corner case of random-access sized but not-common ranges." "If we did want to address such ranges, would be better to enforce commonness for random-access sized ranges by having ranges::end return ranges::begin(r) + ranges::size(r)."

Proposed resolution:

This wording is relative to N4964.

  1. Modify 25.5.3 [view.interface], class template view_interface synopsis, as indicated:

    namespace std::ranges {
  template<class D>
    requires is_class_v<D> && same_as<D, remove_cv_t<D>>
  class view_interface {
    […]
  public:
    […]
    constexpr decltype(auto) back() requires (bidirectional_range<D> && common_range<D>) ||
                                             (random_access_range<D> && sized_range<D>);
    constexpr decltype(auto) back() const
      requires (bidirectional_range<const D> && common_range<const D>) ||
               (random_access_range<const D> && sized_range<const D>);
    […]
  };
}

  2. Modify 25.5.3.2 [view.interface.members] as indicated:

    constexpr decltype(auto) back() requires (bidirectional_range<D> && common_range<D>) ||
                                         (random_access_range<D> && sized_range<D>);
constexpr decltype(auto) back() const
  requires (bidirectional_range<const D> && common_range<const D>) ||
           (random_access_range<const D> && sized_range<const D>);

    -3- Preconditions: !empty() is true.

    -4- Effects: Equivalent to: 

    auto common-arg-end = []<class R>(R& r) {
  if constexpr (common_range<R>) {
    return ranges::end(r);
  } else {
    return ranges::begin(r) + ranges::distance(r);
  }
};
return *ranges::prev(common-arg-endranges::end(derived()));

4006(i). chunk_view::outer-iterator::value_type should provide empty

Section: 25.7.29.4 [range.chunk.outer.value] Status: Tentatively NAD Submitter: Hewill Kang Opened: 2023-11-05 Last modified: 2024-03-11

Priority: Not Prioritized

View all other issues in [range.chunk.outer.value].

View all issues with Tentatively NAD status.

Discussion:

chunk_view::outer-iterator::value_type can determine whether it is empty by simply checking whether the chunk_view's remainder_ is 0, which makes it valuable to explicitly provide a noexcept empty member.

Otherwise, the view_interface::empty is synthesized only through the size member when the original sentinel and iterator type model sized_sentinel_for, which seems overkill: 

#include <cassert>
#include <iostream>
#include <sstream>
#include <ranges>

int main() {
  auto ints = std::istringstream{"1 2 3 4 5 6 7 8 9 10"};
  for (auto chunk : std::views::istream<int>(ints) | std::views::chunk(3)) {
    for (auto elem : chunk) {
      assert(!chunk.empty()); // no matching function for call to 'empty()'
      std::cout << elem << " ";
    }
    assert(chunk.empty()); // ditto
    std::cout << "\n";
  }
}

[2024-03-11; Reflector poll]

Set status to Tentatively NAD after reflector poll in November 2023.

"The example shows you could use it if it existed, but not why that would be useful."

"This is a bad idea - the fact that the chunk 'shrinks' as it is iterated over is an implementation detail and not supposed to be observable."

Proposed resolution:

This wording is relative to N4964.

  1. Modify 25.7.29.4 [range.chunk.outer.value] as indicated:

      namespace std::ranges {
    template<view V>
      requires input_range<V>
    struct chunk_view<V>::outer-iterator::value_type : view_interface<value_type> {
    private:
      chunk_view* parent_;                                        // exposition only

      constexpr explicit value_type(chunk_view& parent);          // exposition only

    public:
      constexpr inner-iterator begin() const noexcept;
      constexpr default_sentinel_t end() const noexcept;

      constexpr bool empty() const noexcept;
      constexpr auto size() const
        requires sized_sentinel_for<sentinel_t<V>, iterator_t<V>>;
    };
  }
    […] 
    constexpr default_sentinel_t end() const noexcept;

    -3- Returns: default_sentinel. 

    constexpr bool empty() const noexcept;

    -?- Effects: Equivalent to: return parent_->remainder_ == 0;

4095(i). ranges::fold_meow should explicitly spell out the return type

Section: 26.4 [algorithm.syn], 26.6.18 [alg.fold] Status: Tentatively NAD Submitter: Hewill Kang Opened: 2024-05-03 Last modified: 2024-06-24

Priority: Not Prioritized

View other active issues in [algorithm.syn].

View all other issues in [algorithm.syn].

View all issues with Tentatively NAD status.

Discussion:

Unlike other algorithms, the return types of ranges::fold_meow are specified in terms of auto and see below, and its implementation details depend on the return types of other overloads through decltype(fold_meow(...)).

This makes determining the return type of a certain overload (such as fold_right_last) extremely difficult even for experts, requiring several trips back and forth to different overloads to finally understand what the actual return type is. The situation is even worse for newbies because such a form of specifying the return type makes it impossible for the IDE to deduce the real return type, which is extremely user-unfriendly.

I think that explicitly specifying the return type for these overloads not only greatly improves readability but also offloads the compiler from deducing the return type, which can definitely be considered an improvement.

The proposed resolution does not touch the Effects clause and only changes the function signature to seek minimal changes.

[2024-06-24; Reflector poll: NAD]

Implementations are free to spell this out if desired.

Proposed resolution:

This wording is relative to N4981.

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

    #include <initializer_list>     // see 17.11.2 [initializer.list.syn]

namespace std {
  […]
  namespace ranges {
    […]
    template<input_iterator I, sentinel_for<I> S, class T = iter_value_t<I>,
             indirectly-binary-left-foldable<T, I> F>
      constexpr auto fold_left(I first, S last, T init, F f) ->
        decay_t<invoke_result_t<F&, T, iter_reference_t<I>>>;

    template<input_range R, class T = range_value_t<R>,
             indirectly-binary-left-foldable<T, iterator_t<R>> F>
      constexpr auto fold_left(R&& r, T init, F f) ->
        decay_t<invoke_result_t<F&, T, range_reference_t<R>>>;

    template<input_iterator I, sentinel_for<I> S,
             indirectly-binary-left-foldable<iter_value_t<I>, I> F>
      requires constructible_from<iter_value_t<I>, iter_reference_t<I>>
      constexpr auto fold_left_first(I first, S last, F f) ->
        optional<decay_t<invoke_result_t<F&, iter_value_t<I>, iter_reference_t<I>>>>;

    template<input_range R, indirectly-binary-left-foldable<range_value_t<R>, iterator_t<R>> F>
      requires constructible_from<range_value_t<R>, range_reference_t<R>>
      constexpr auto fold_left_first(R&& r, F f) ->
        optional<decay_t<invoke_result_t<F&, range_value_t<R>, range_reference_t<R>>>>;

    template<bidirectional_iterator I, sentinel_for<I> S, class T = iter_value_t<I>,
             indirectly-binary-right-foldable<T, I> F>
      constexpr auto fold_right(I first, S last, T init, F f) ->
        decay_t<invoke_result_t<F&, iter_reference_t<I>, T>>;

    template<bidirectional_range R, class T = range_value_t<R>,
             indirectly-binary-right-foldable<T, iterator_t<R>> F>
      constexpr auto fold_right(R&& r, T init, F f) ->
        decay_t<invoke_result_t<F&, range_reference_t<R>, T>>;

    template<bidirectional_iterator I, sentinel_for<I> S,
             indirectly-binary-right-foldable<iter_value_t<I>, I> F>
      requires constructible_from<iter_value_t<I>, iter_reference_t<I>>
    constexpr auto fold_right_last(I first, S last, F f) ->
      optional<decay_t<invoke_result_t<F&, iter_reference_t<I>, iter_value_t<I>>>>;

    template<bidirectional_range R,
             indirectly-binary-right-foldable<range_value_t<R>, iterator_t<R>> F>
      requires constructible_from<range_value_t<R>, range_reference_t<R>>
    constexpr auto fold_right_last(R&& r, F f) ->
      optional<decay_t<invoke_result_t<F&, range_reference_t<R>, range_value_t<R>>>>;

    template<class I, class T>
      using fold_left_with_iter_result = in_value_result<I, T>;
    template<class I, class T>
      using fold_left_first_with_iter_result = in_value_result<I, T>;

    template<input_iterator I, sentinel_for<I> S, class T = iter_value_t<I>,
             indirectly-binary-left-foldable<T, I> F>
      constexpr see belowauto fold_left_with_iter(I first, S last, T init, F f) ->
        fold_left_with_iter_result<I, decay_t<invoke_result_t<F&, T, iter_reference_t<I>>>>;

    template<input_range R, class T = range_value_t<R>,
             indirectly-binary-left-foldable<T, iterator_t<R>> F>
      constexpr see belowauto fold_left_with_iter(R&& r, T init, F f) ->
        fold_left_with_iter_result<borrowed_iterator_t<R>,
                                   decay_t<invoke_result_t<F&, T, range_reference_t<R>>>>;

    template<input_iterator I, sentinel_for<I> S,
             indirectly-binary-left-foldable<iter_value_t<I>, I> F>
      requires constructible_from<iter_value_t<I>, iter_reference_t<I>>
      constexpr see belowauto fold_left_first_with_iter(I first, S last, F f) ->
        fold_left_first_with_iter_result<
          I, optional<decay_t<invoke_result_t<F&, iter_value_t<I>, iter_reference_t<I>>>>>;

    template<input_range R,
             indirectly-binary-left-foldable<range_value_t<R>, iterator_t<R>> F>
      requires constructible_from<range_value_t<R>, range_reference_t<R>>
      constexpr see belowauto fold_left_first_with_iter(R&& r, F f) ->
        fold_left_first_with_iter_result<
          borrowed_iterator_t<R>,
          optional<decay_t<invoke_result_t<F&, range_value_t<R>, range_reference_t<R>>>>>;
  }
  […]
}

  2. Modify 26.6.18 [alg.fold] as indicated:

    template<input_iterator I, sentinel_for<I> S, class T = iter_value_t<I>,
         indirectly-binary-left-foldable<T, I> F>
constexpr auto ranges::fold_left(I first, S last, T init, F f) ->
  decay_t<invoke_result_t<F&, T, iter_reference_t<I>>>;

template<input_range R, class T = range_value_t<R>,
         indirectly-binary-left-foldable<T, iterator_t<R>> F>
constexpr auto ranges::fold_left(R&& r, T init, F f) ->
  decay_t<invoke_result_t<F&, T, range_reference_t<R>>>;

    -1- Returns: 

    ranges::fold_left_with_iter(std::move(first), last, std::move(init), f).value

    template<input_iterator I, sentinel_for<I> S,
         indirectly-binary-left-foldable<iter_value_t<I>, I> F>
  requires constructible_from<iter_value_t<I>, iter_reference_t<I>>
  constexpr auto ranges::fold_left_first(I first, S last, F f) ->
    optional<decay_t<invoke_result_t<F&, iter_value_t<I>, iter_reference_t<I>>>>;

template<input_range R, indirectly-binary-left-foldable<range_value_t<R>, iterator_t<R>> F>
  requires constructible_from<range_value_t<R>, range_reference_t<R>>
  constexpr auto ranges::fold_left_first(R&& r, F f) ->
    optional<decay_t<invoke_result_t<F&, range_value_t<R>, range_reference_t<R>>>>;

    -2- Returns: 

    ranges::fold_left_first_with_iter(std::move(first), last, f).value

    template<bidirectional_iterator I, sentinel_for<I> S, class T = iter_value_t<I>,
         indirectly-binary-right-foldable<T, I> F>
  constexpr auto ranges::fold_right(I first, S last, T init, F f) ->
    decay_t<invoke_result_t<F&, iter_reference_t<I>, T>>;

template<bidirectional_range R, class T = range_value_t<R>,
        indirectly-binary-right-foldable<T, iterator_t<R>> F>
  constexpr auto ranges::fold_right(R&& r, T init, F f) ->
    decay_t<invoke_result_t<F&, range_reference_t<R>, T>>;

    -3- Effects: Equivalent to: 

    using U = decay_t<invoke_result_t<F&, iter_reference_t<I>, T>>;
if (first == last)
  return U(std::move(init));
I tail = ranges::next(first, last);
U accum = invoke(f, *--tail, std::move(init));
while (first != tail)
  accum = invoke(f, *--tail, std::move(accum));
return accum;

    template<bidirectional_iterator I, sentinel_for<I> S,
        indirectly-binary-right-foldable<iter_value_t<I>, I> F>
  requires constructible_from<iter_value_t<I>, iter_reference_t<I>>
constexpr auto ranges::fold_right_last(I first, S last, F f) ->
  optional<decay_t<invoke_result_t<F&, iter_reference_t<I>, iter_value_t<I>>>>;

template<bidirectional_range R,
         indirectly-binary-right-foldable<range_value_t<R>, iterator_t<R>> F>
 requires constructible_from<range_value_t<R>, range_reference_t<R>>
constexpr auto ranges::fold_right_last(R&& r, F f) ->
  optional<decay_t<invoke_result_t<F&, range_reference_t<R>, range_value_t<R>>>>;

    -4- Let U be decltype(ranges::fold_right(first, last, iter_value_t<I>(*first), f)).

    -5- Effects: Equivalent to: 

    if (first == last)
  return optional<U>();
I tail = ranges::prev(ranges::next(first, std::move(last)));
return optional<U>(in_place,
  ranges::fold_right(std::move(first), tail, iter_value_t<I>(*tail), std::move(f)));

    template<input_iterator I, sentinel_for<I> S, class T = iter_value_t<I>,
         indirectly-binary-left-foldable<T, I> F>
  constexpr see belowauto ranges::fold_left_with_iter(I first, S last, T init, F f) ->
    fold_left_with_iter_result<I, decay_t<invoke_result_t<F&, T, iter_reference_t<I>>>>;

template<input_range R, class T = range_value_t<R>,
         indirectly-binary-left-foldable<T, iterator_t<R>> F>
  constexpr see belowauto ranges::fold_left_with_iter(R&& r, T init, F f) ->
    fold_left_with_iter_result<borrowed_iterator_t<R>,
                               decay_t<invoke_result_t<F&, T, range_reference_t<R>>>>;

    -6- Let U be decay_t<invoke_result_t<F&, T, iter_reference_t<I>>>.

    -7- Effects: Equivalent to: 

    if (first == last)
  return {std::move(first), U(std::move(init))};
U accum = invoke(f, std::move(init), *first);
for (++first; first != last; ++first)
  accum = invoke(f, std::move(accum), *first);
return {std::move(first), std::move(accum)};

    -8- Remarks: The return type is fold_left_with_iter_result<I, U> for the first overload and fold_left_with_iter_result<borrowed_iterator_t<R>, U> for the second overload. 

    template<input_iterator I, sentinel_for<I> S,
         indirectly-binary-left-foldable<iter_value_t<I>, I> F>
  requires constructible_from<iter_value_t<I>, iter_reference_t<I>>
  constexpr see belowauto ranges::fold_left_first_with_iter(I first, S last, F f) ->
    fold_left_first_with_iter_result<
      I, optional<decay_t<invoke_result_t<F&, iter_value_t<I>, iter_reference_t<I>>>>>;

template<input_range R,
         indirectly-binary-left-foldable<range_value_t<R>, iterator_t<R>> F>
  requires constructible_from<range_value_t<R>, range_reference_t<R>>
  constexpr see belowauto ranges::fold_left_first_with_iter(R&& r, F f) ->
    fold_left_first_with_iter_result<
      borrowed_iterator_t<R>,
      optional<decay_t<invoke_result_t<F&, range_value_t<R>, range_reference_t<R>>>>>;

    -9- Let U be 

    decltype(ranges::fold_left(std::move(first), last, iter_value_t<I>(*first), f))

    -10- Effects: Equivalent to: 

    if (first == last)
  return {std::move(first), optional<U>()};
optional<U> init(in_place, *first);
for (++first; first != last; ++first)
  *init = invoke(f, std::move(*init), *first);
return {std::move(first), std::move(init)};

    -11- Remarks: The return type is fold_left_first_with_iter_result<I, optional<U>> for the first overload and fold_left_first_with_iter_result<borrowed_iterator_t<R>, optional<U>> for the second overload.

4163(i). Can the overload of std::num_get::do_get for bool call the overload for long?

Section: 28.3.4.3.2.3 [facet.num.get.virtuals] Status: Tentatively NAD Submitter: Jiang An Opened: 2024-09-29 Last modified: 2025-02-07

Priority: Not Prioritized

View other active issues in [facet.num.get.virtuals].

View all other issues in [facet.num.get.virtuals].

View all issues with Tentatively NAD status.

Discussion:

28.3.4.3.2.3 [facet.num.get.virtuals]/6 currently says:

Effects: If (str.flags()&ios_base::boolalpha) == 0 then input proceeds as it would for a long except that if a value is being stored into val, […]

It is unclear whether an implementation is allowed to call the overload for long in this case. Currently, libc++'s version calls that overload, while libstdc++ and MSVC STL's don't (example).

As the divergence implementation strategies is observable, perhaps we should clarify on this.

[2025-02-07; Reflector poll: NAD]

I think this is just a libc++ bug. The wording says it "proceeds as it would for long", which is not the same as actually making a virtual call to do_get for long. It can either duplicate the code from do_get for long, or make a non-virtual (i.e. qualified) call to num_get::do_get.

Proposed resolution:

4184(i). Domain of ranges::cmeow doesn't match ranges::meow

Section: 25.3 [range.access] Status: Tentatively NAD Submitter: Hewill Kang Opened: 2024-12-17 Last modified: 2025-02-07

Priority: Not Prioritized

View all issues with Tentatively NAD status.

Discussion:

ranges::begin/rbegin/data can be used on non-ranges as long as the object has a begin/rbegin/data member, this is also true for their const versions before C++23.

However, in C++23 the const version always applied possibly-const-range to the object, which no longer worked for non-ranges due to this function requiring input_range, which seems to be a breaking change (demo): 

#include <ranges>

struct NotRange {
        int* begin();
  const int* begin() const;
        int* rbegin();
  const int* rbegin() const;
        int* data();
  const int* data() const;
};

int main() {
  NotRange r;

  (void) std::ranges::begin(r);
  (void) std::ranges::rbegin(r);
  (void) std::ranges::data(r);

  // The following works in C++20, fails in C++23
  (void) std::ranges::cbegin(r);
  (void) std::ranges::crbegin(r);
  (void) std::ranges::cdata(r);
}

[2025-02-07; Reflector poll: NAD]

"We don't need to support ranges::cbegin on non-ranges."

"Seems to be very similar to LWG 3913(i) which LWG closed as NAD."

Proposed resolution:

4194(i). atomic<void*> should use generic class template

Section: 32.5.8.5 [atomics.types.pointer] Status: Tentatively NAD Submitter: Gonzalo Brito Opened: 2025-01-16 Last modified: 2025-02-07

Priority: Not Prioritized

View other active issues in [atomics.types.pointer].

View all other issues in [atomics.types.pointer].

View all issues with Tentatively NAD status.

Discussion:

32.5.8.5 [atomics.types.pointer] p1 states (emphasis mine):

There is a partial specialization of the atomic class template for pointers.

which requires atomic<void*> to use the atomic class template for pointers. However, the fetch_add/_sub member functions add a difference_type to a T* which requires a pointer-to-object type (these member functions are constexpr, so trying to support this seems unimplementable).

For atomic_ref, the 32.5.7.5 [atomics.ref.pointer] p1 states (emphasis mine):

There are specializations of the atomic_ref` class template for all pointer-to-object types.

which avoids this issue and applying the same form to 32.5.8.5 [atomics.types.pointer] would make atomic<void*> and atomic_ref<void*> consistent.

Technically this would be a breaking change, but all C++ standard library implementations surveyed are broken, and the proposed fix would make them compliant: see libstdc++, libc++ and MSVC STL errors here. These standard libraries require a pointer-to-object type, atomic<void*> uses the general template. Therefore, no user code seems to be impacted.

[2025-02-07; Reflector poll: NAD]

The fetch_OP members have "Mandates: T is a complete object type." and a note explaining that this means arithmetic on void* is ill-formed. So implementations are expected to use the partial specialization for void* but to reject attempts at arithmetic. They all do this correctly today.

Proposed resolution:

This wording is relative to N5001.

  1. Modify 32.5.8.5 [atomics.types.pointer] as indicated:

    -1- There is a partial specialization of the atomic class template for pointerspointer-to-object types. Specializations of this partial specialization are standard-layout structs. They each have a trivial destructor.

4228(i). Does vector<bool, Allocator> mandate that Allocator::value_type is bool?

Section: 23.3.14.1 [vector.bool.pspc] Status: Tentatively NAD Submitter: Stephan T. Lavavej Opened: 2025-03-18 Last modified: 2025-06-13

Priority: Not Prioritized

View all other issues in [vector.bool.pspc].

View all issues with Tentatively NAD status.

Discussion:

N5008 23.3.14.1 [vector.bool.pspc]/2 says:

Unless described below, all operations have the same requirements and semantics as the primary vector template, except that operations dealing with the bool value type map to bit values in the container storage and allocator_traits::construct (20.2.9.3 [allocator.traits.members]) is not used to construct these values.

23.2.2.5 [container.alloc.reqmts]/5 says:

Mandates: allocator_type::value_type is the same as X::value_type.

Is vector<bool, allocator<int>> forbidden? There's implementation divergence: MSVC's STL enforces the mandate, while libc++ and libstdc++ accept this code, discovered while running libc++'s tests with MSVC's STL.

Preferred resolution: I would be satisfied with resolving this as NAD, with a record that LWG believes that "all operations have the same requirements" means that the Mandate applies. I suppose that an editorial note could also be added to this effect, although I don't believe it's necessary.

Alternate resolution: If LWG believes that the Mandate does not apply, and that vector<bool> should be unique among containers in accepting allocator<Anything>, then I believe that a normative sentence should be added to 23.3.14.1 [vector.bool.pspc]/2, specifically creating an exemption to 23.2.2.5 [container.alloc.reqmts]/5.

[2025-06-13; Reflector poll]

Set status to Tentatively NAD. This is just a bug in some implementations (now fixed in libstdc++).

Proposed resolution:

4246(i). Redundant constraint in range_formatter::format

Section: 28.5.7.2 [format.range.formatter] Status: Tentatively NAD Submitter: Hewill Kang Opened: 2025-04-18 Last modified: 2025-06-12

Priority: Not Prioritized

View all other issues in [format.range.formatter].

View all issues with Tentatively NAD status.

Discussion:

Currently, the signature of range_formatter::format is as follows: 

template<ranges::input_range R, class FormatContext>
  requires formattable<ranges::range_reference_t<R>, charT> &&
           same_as<remove_cvref_t<ranges::range_reference_t<R>>, T>
typename FormatContext::iterator
  format(R&& r, FormatContext& ctx) const;

which requires that the reference type of the range parameter must be formattable, and such type must be exactly T after removing the cvref-qualifiers.

However, satisfying the latter always implies satisfying the former, as the range_formatter class already requires that T must be formattable.

There is no need to perform a redundant check here.

[2025-06-12; Reflector poll]

Set status to Tentatively NAD. This is not redundant, it might check that const T is formattable, which is not the same as checking that T is formattable.

Proposed resolution:

This wording is relative to N5008.

  1. Modify 28.5.7.2 [format.range.formatter] as indicated:

    namespace std {
  template<class T, class charT = char>
    requires same_as<remove_cvref_t<T>, T> && formattable<T, charT>
  class range_formatter {
    […]
    template<ranges::input_range R, class FormatContext>
        requires formattable<ranges::range_reference_t<R>, charT> &&
                 same_as<remove_cvref_t<ranges::range_reference_t<R>>, T>
      typename FormatContext::iterator
        format(R&& r, FormatContext& ctx) const;
  };
}
    […] 
    template<ranges::input_range R, class FormatContext>
  requires formattable<ranges::range_reference_t<R>, charT> &&
           same_as<remove_cvref_t<ranges::range_reference_t<R>>, T>
typename FormatContext::iterator
  format(R&& r, FormatContext& ctx) const;

    -11- Effects: Writes the following into ctx.out(), adjusted according to the range-format-spec:

4253(i). basic_const_iterator should provide iterator_type

Section: 24.5.3.3 [const.iterators.iterator] Status: Tentatively Ready Submitter: Hewill Kang Opened: 2025-04-29 Last modified: 2025-06-13

Priority: Not Prioritized

View other active issues in [const.iterators.iterator].

View all other issues in [const.iterators.iterator].

View all issues with Tentatively Ready status.

Discussion:

Currently, iterator adaptors in <iterator> that wrap a single iterator such as reverse_iterator, move_iterator, and counted_iterator all provide a public iterator_type member for users to access the underlying iterator type, except for basic_const_iterator (demo): 

#include <iterator>

using I  = int*;
using RI = std::reverse_iterator<I>;
using MI = std::move_iterator<I>;
using CI = std::counted_iterator<I>;
using BI = std::basic_const_iterator<I>;

static_assert(std::same_as<RI::iterator_type, I>);
static_assert(std::same_as<MI::iterator_type, I>);
static_assert(std::same_as<CI::iterator_type, I>);
static_assert(std::same_as<BI::iterator_type, I>); // error

It seems reasonable to add one for basic_const_iterator for consistency.

[2025-06-12; Reflector poll]

Set status to Tentatively Ready after eight votes in favour during reflector poll.

Proposed resolution:

This wording is relative to N5008.

  1. Modify 24.5.3.3 [const.iterators.iterator] as indicated:

    namespace std {
  […]
  template<input_iterator Iterator>
  class basic_const_iterator {
    Iterator current_ = Iterator();                             // exposition only
    using reference = iter_const_reference_t<Iterator>;         // exposition only
    using rvalue-reference =                                    // exposition only
      iter-const-rvalue-reference-t<Iterator>;
          
    public:
      using iterator_type = Iterator;
      using iterator_concept = see below;
      using iterator_category = see below;  // not always present
      using value_type = iter_value_t<Iterator>;
      using difference_type = iter_difference_t<Iterator>;
      […]
  };
}

4257(i). Stream insertion for chrono::local_time should be constrained

Section: 30.7.9 [time.clock.local] Status: Tentatively Ready Submitter: Jonathan Wakely Opened: 2025-05-16 Last modified: 2025-08-26

Priority: Not Prioritized

View all issues with Tentatively Ready status.

Discussion:

Stream insertion for chrono::local_time is defined in terms of conversion to chrono::sys_time, but not all chrono::sys_time specializations can be inserted into an ostream, because one of the overloads is constrained and the other requires convertibility to chrono::sys_days (see 30.7.2.3 [time.clock.system.nonmembers]).

This means the following code fails to compile: 


#include <iostream>
#include <chrono>

template<typename T>
concept ostream_insertable = requires (std::ostream& o, const T& t) { o << t; };

using D = std::chrono::duration<double>;

int main() {
  if constexpr (ostream_insertable<std::chrono::sys_time<D>>)
    std::cout << std::chrono::sys_time<D>{};
  if constexpr (ostream_insertable<std::chrono::local_time<D>>)
    std::cout << std::chrono::local_time<D>{}; // FAIL
}
The first condition is false, because there's no overload that's suitable. The second is true, because the operator<< overload for chrono::local_time isn't constrained and so insertion appears to be valid. But actually trying to use it is ill-formed, because it tries to convert the local_time<D> to a sys_time<D> and then insert that, which isn't valid.

[2025-08-21; Reflector poll]

Set status to Tentatively Ready after six votes in favour during reflector poll.

Proposed resolution:

This wording is relative to N5008.

  1. Modify 30.7.9 [time.clock.local] as indicated:

    
template<class charT, class traits, class Duration>
  basic_ostream<charT, traits>&
    operator<<(basic_ostream<charT, traits>& os, const local_time<Duration>& lt);

    -?- Constraints: os << sys_time<Duration>{lt.time_since_epoch()} is a valid expression.

    -2- Effects: 

     os << sys_time<Duration>{lt.time_since_epoch()};

    -3- Returns: os.

4266(i). layout_stride::mapping should treat empty mappings as exhaustive

Section: 23.7.3.4.7 [mdspan.layout.stride] Status: Tentatively Ready Submitter: Tomasz Kamiński Opened: 2025-05-22 Last modified: 2025-06-13

Priority: Not Prioritized

View all other issues in [mdspan.layout.stride].

View all issues with Tentatively Ready status.

Discussion:

Mapping over an empty multidimensional index space is always exhaustive according to the corresponding definitions from 23.7.3.4.2 [mdspan.layout.reqmts] p16.

However, the current specification of layout_stride::mapping does not consider whether some of the empty multidimensional index spaces are unique or exhaustive. For illustration, the mapping with the following configuration is not considered exhaustive according to the current specification of 23.7.3.4.7.4 [mdspan.layout.stride.obs] bullet 5.2: 

extents: 2, 2, 0
strides: 2, 6, 20

This prevents the implementation from implementing sm.is_exhaustive() as sm.fwd-prod-of-extents(sm::extents_type::rank()) == sm.required_span_size(). For all mappings with size greater than zero, such an expression provides an answer consistent with the standard. However, it always returns true for an empty mapping, such as shown in the example.

We should make such implementation conforming, and require is_exhaustive() to return true for empty mappings.

For consistency, we could update is_always_exhaustive() to recognize mapping with rank() == 0, and one for which at least one of the static extents is equal to zero (i.e., they always represent a multidimensional index space).

[2025-06-12; Reflector poll]

Set status to Tentatively Ready after six votes in favour during reflector poll.

Proposed resolution:

This wording is relative to N5008.

  1. Modify 23.7.3.4.7.1 [mdspan.layout.stride.overview] as indicated:

    namespace std {
  template<class Extents>
  class layout_stride::mapping {
    […]
    static constexpr bool is_always_unique() noexcept { return true; }
    static constexpr bool is_always_exhaustive() noexcept; { return false; }
    static constexpr bool is_always_strided() noexcept { return true; }
    […]
  };
}

  2. Modify 23.7.3.4.7.4 [mdspan.layout.stride.obs] as indicated:

    […] 

    static constexpr bool is_always_exhaustive() noexcept;

    -?- Returns: true if rank_ is 0 or if there is a rank index r of extents() such that extents_type::static_extent(r) is 0, otherwise false. 

    constexpr bool is_exhaustive() const noexcept;

    -5- Returns:

    1. (5.1) — true if rank_ or the size of the multidimensional index space m.extents() is 0.

    2. (5.2) — […]

    3. (5.3) — […]

4274(i). The chrono::hh_mm_ss constructor is ill-formed for unsigned durations

Section: 30.9.2 [time.hms.members] Status: Tentatively Ready Submitter: Michael Welsh Duggan Opened: 2025-06-04 Last modified: 2025-06-13

Priority: Not Prioritized

View all issues with Tentatively Ready status.

Discussion:

In 30.9.2 [time.hms.members], paragraph 3, the current wording for the constructor of hh_mm_ss expresses some of its requirements in terms of abs(d), which is assumed to be chrono::abs(chrono::duration). chrono::abs is not defined, however, for durations with an unsigned representation. I believe that not being able to create hh_mm_ss objects from unsigned durations is unintentional.

Moreover, is_constructible_v<hh_mm_ss<ud>, ud> is required to be true by the standard for any duration, so making it actually work makes a lot of sense.

[2025-06-13; Reflector poll]

Set status to Tentatively Ready after five votes in favour during reflector poll.

Proposed resolution:

This wording is relative to N5008.

  1. Modify 30.9.2 [time.hms.members] as indicated:

    constexpr explicit hh_mm_ss(Duration d);

    -3- Effects: Constructs an object of type hh_mm_ss which represents the Duration d with precision precision.

    1. (3.1) — Initializes is_neg with d < Duration::zero(). Let ABS_D represent -d if is_neg is true and d otherwise.

    2. (3.2) — Initializes h with duration_cast<chrono::hours>(abs(d)ABS_D).

    3. (3.3) — Initializes m with duration_cast<chrono::minutes>(abs(d)ABS_D - hours()).

    4. (3.4) — Initializes s with duration_cast<chrono::seconds>(abs(d)ABS_D - hours() - minutes()).

    5. (3.5) — If treat_as_floating_point_v<precision::rep> is true, initializes ss with abs(d)ABS_D - hours() - minutes() - seconds(). Otherwise, initializes ss with duration_cast<precision>(abs(d)ABS_D - hours() - minutes() - seconds()).

4276(i). front() and back() are not hardened for zero-length std::arrays

Section: 23.3.3.5 [array.zero] Status: Tentatively Ready Submitter: Jan Schultke Opened: 2025-06-08 Last modified: 2025-08-26

Priority: Not Prioritized

View other active issues in [array.zero].

View all other issues in [array.zero].

View all issues with Tentatively Ready status.

Discussion:

The intent of P3471 "Standard library hardening" is clearly to provide hardened preconditions for members of sequence containers, including std::array. However, a zero-length std::array dodges this hardening by having undefined behavior for front() and back() explicitly specified in 23.3.3.5 [array.zero] paragraph 3.

Without this paragraph, front() and back() would be hardened as well, as specified in 23.2.4 [sequence.reqmts].

[2025-08-21; Reflector poll]

Set status to Tentatively Ready after eight votes in favour during reflector poll.

Proposed resolution:

This wording is relative to N5008.

  1. Modify 23.3.3.5 [array.zero] as indicated:

    -3- The effect of calling front() or back() for a zero-sized array is undefined.

4280(i). simd::partial_load uses undefined identifier T

Section: 29.10.8.7 [simd.loadstore] Status: Tentatively Ready Submitter: Tim Song Opened: 2025-06-21 Last modified: 2025-08-26

Priority: Not Prioritized

View all issues with Tentatively Ready status.

Discussion:

The Effects: element of std::simd::partial_load (after the latest rename) uses T but that is not defined anywhere. It should be V::value_type.

Also, this paragraph should be a Returns: element.

[2025-08-21; Reflector poll]

Set status to Tentatively Ready after nine votes in favour during reflector poll.

Proposed resolution:

This wording is relative to N5008.

  1. Modify 29.10.8.7 [simd.loadstore] as indicated:

    
template<class V = see below, ranges::contiguous_range R, class... Flags>
  requires ranges::sized_range<R>
  constexpr V partial_load(R&& r, flags<Flags...> f = {});
[…]
template<class V = see below, contiguous_iterator I, sized_sentinel_for<I> S, class... Flags>
  constexpr V partial_load(I first, S last, const typename V::mask_type& mask,
                           flags<Flags...> f = {});

    -6- […]

    -7- Mandates: […]

    -8- Preconditions: […]

    -9- Effects: Initializes theReturns: A basic_simd object whose ith element is initialized with mask[i] && i < ranges::size(r) ? static_cast<T>(ranges::data(r)[i]) : T() for all i in the range of [0, V::size()), where T is V::value_type.

    -10- Remarks: The default argument for template parameter V is basic_simd<ranges::range_value_t<R>>.

4291(i). explicit map(const Allocator&) should be constexpr

Section: 23.4.3.1 [map.overview] Status: Tentatively Ready Submitter: Jonathan Wakely Opened: 2025-07-10 Last modified: 2025-08-26

Priority: Not Prioritized

View other active issues in [map.overview].

View all other issues in [map.overview].

View all issues with Tentatively Ready status.

Discussion:

The intent of P3372R3 was for all container constructors to be constexpr, but during application of the paper to the working draft it was observed that one map constructor was missed.

[2025-08-21; Reflector poll]

Set status to Tentatively Ready after six votes in favour during reflector poll.

Proposed resolution:

This wording is relative to N5008.

  1. Modify 23.4.3.1 [map.overview] as indicated:

    
// 23.4.3.2, construct/copy/destroy
constexpr map() : map(Compare()) { }
constexpr explicit map(const Compare& comp, const Allocator& = Allocator());
template<class InputIterator>
  constexpr map(InputIterator first, InputIterator last,
                const Compare& comp = Compare(), const Allocator& = Allocator());
template<container-compatible-range <value_type> R>
  constexpr map(from_range_t, R&& rg, const Compare& comp = Compare(),
                const Allocator& = Allocator());
constexpr map(const map& x);
constexpr map(map&& x);
constexpr explicit map(const Allocator&);
constexpr map(const map&, const type_identity_t<Allocator>&);
constexpr map(map&&, const type_identity_t<Allocator>&);
constexpr map(initializer_list<value_type>, const Compare& = Compare(),
              const Allocator& = Allocator());

4292(i). Unordered container local iterators should be constexpr iterators

Section: 23.5.3.1 [unord.map.overview], 23.5.4.1 [unord.multimap.overview], 23.5.6.1 [unord.set.overview], 23.5.7.1 [unord.multiset.overview] Status: Tentatively Ready Submitter: Jonathan Wakely Opened: 2025-07-10 Last modified: 2025-08-29

Priority: Not Prioritized

View all issues with Tentatively Ready status.

Discussion:

The intent of P3372R3 was for all container iterators to be constexpr iterators, but during application of the paper to the working draft it was observed that unordered containers don't say it for their local iterators.

[2025-08-29; Reflector poll]

Set status to Tentatively Ready after eight votes in favour during reflector poll.

Proposed resolution:

This wording is relative to N5008.

  1. Modify 23.5.3.1 [unord.map.overview] as indicated:

    -4- The types iterator, and const_iterator, local_iterator, and const_local_iterator meet the constexpr iterator requirements (24.3.1 [iterator.requirements.general]).

  2. Modify 23.5.4.1 [unord.multimap.overview] as indicated:

    -4- The types iterator, and const_iterator, local_iterator, and const_local_iterator meet the constexpr iterator requirements (24.3.1 [iterator.requirements.general]).

  3. Modify 23.5.6.1 [unord.set.overview] as indicated:

    -4- The types iterator, and const_iterator, local_iterator, and const_local_iterator meet the constexpr iterator requirements (24.3.1 [iterator.requirements.general]).

  4. Modify 23.5.7.1 [unord.multiset.overview] as indicated:

    -4- The types iterator, and const_iterator, local_iterator, and const_local_iterator meet the constexpr iterator requirements (24.3.1 [iterator.requirements.general]).

4293(i). span::subspan/first/last chooses wrong constructor when T is const-qualified bool

Section: 23.7.2.2.4 [span.sub] Status: Tentatively Ready Submitter: Yuhan Liu Opened: 2025-07-11 Last modified: 2025-08-26

Priority: Not Prioritized

View all other issues in [span.sub].

View all issues with Tentatively Ready status.

Discussion:

In section 23.7.2.2.4 [span.sub], paragraphs p12, p14, and p16 erroneously use the initializer list constructor for span instead of the intended iterator/count constructor.

Specifically, in these paragraphs, the standard states:

Effects: Equivalent to: return {data(), count};
or some variant of return {pointer, size}. As reported in GCC bug 120997 this results in a span that points to invalid stack memory. This can be reproduced on GCC 15.1 for subspan, first, and last: https://godbolt.org/z/r9nrdWscq.

A proposed fix (thanks to Jonathan Wakely) could look like this following:

return span<element_type>(data(), count);
for the affected paragraphs, which would explicitly specify the constructor used.

[2025-07-11; Jonathan adds proposed resolution]

The meaning of those Effects: paragraphs was changed for C++26 by P2447R6 which added the span(initializer_list) constructor. A simpler demo is: 

bool a[5]{};
std::span<const bool> s(a);
std::span<const bool> s2 = s.first(5);
assert(s2.size() == 5); // OK in C++23, fails in C++26
assert(s2.data() == a); // OK in C++23, fails in C++26
The proposed resolution is to use R(data(), count) instead of {data(), count}. The former always (uniformly) means the same thing, but for the latter the meaning of list-initialization depends on the types. The list-initialization form will choose the initializer-list constructor when data() and count are both convertible to the element type.

[2025-08-21; Reflector poll]

Set status to Tentatively Ready after nine votes in favour during reflector poll.

Proposed resolution:

This wording is relative to N5008.

  1. Modify 23.7.2.2.4 [span.sub] as indicated:

    
template<size_t Count> constexpr span<element_type, Count> first() const;

    -1- Mandates: Count <= Extent is true.

    -2- Hardened preconditions: Count <= size() is true.

    -3- Effects: Equivalent to: return R({data(), Count}); where R is the return type. 

    
template<size_t Count> constexpr span<element_type, Count> last() const;

    -4- Mandates: Count <= Extent is true.

    -5- Hardened preconditions: Count <= size() is true.

    -6- Effects: Equivalent to: return R({data() + (size() - Count), Count}); where R is the return type. 

    
template<size_t Offset, size_t Count = dynamic_extent>
  constexpr span<element_type, see below> subspan() const;

    -7- Mandates: 

    Offset <= Extent && (Count == dynamic_extent || Count <= Extent - Offset)
    is true.

    -8- Hardened preconditions: 

    Offset <= size() && (Count == dynamic_extent || Count <= size() - Offset)
    is true.

    -9- Effects: Equivalent to: 

    return span<ElementType, see below>(
    data() + Offset, Count != dynamic_extent ? Count : size() - Offset);

    -10- Remarks: The second template argument of the returned span type is: 

    Count != dynamic_extent ? Count
                        : (Extent != dynamic_extent ? Extent - Offset
                                                    : dynamic_extent)


    
constexpr span<element_type, dynamic_extent> first(size_type count) const;

    -11- Hardened preconditions: count <= size() is true.

    -12- Effects: Equivalent to: return R({data(), count}); where R is the return type. 

    
constexpr span<element_type, dynamic_extent> last(size_type count) const;

    -13- Hardened preconditions: count <= size() is true.

    -14- Effects: Equivalent to: return R({data() + (size() - count), count}); where R is the return type. 

    
constexpr span<element_type, dynamic_extent> subspan(
  size_type offset, size_type count = dynamic_extent) const;

    -15- Hardened preconditions: 

    offset <= size() && (count == dynamic_extent || count <= size() - offset
    is true.

    -16- Effects: Equivalent to: 

    return R({data() + offset, count == dynamic_extent ? size() - offset :  count});
    where R is the return type.

4294(i). bitset(const CharT*) constructor needs to be constrained

Section: 22.9.2.2 [bitset.cons] Status: Tentatively Ready Submitter: Jonathan Wakely Opened: 2025-07-12 Last modified: 2025-08-26

Priority: Not Prioritized

View all other issues in [bitset.cons].

View all issues with Tentatively Ready status.

Discussion:

This code might be ill-formed, with an error outside the immediate context that users cannot prevent: 


#include <bitset>
struct NonTrivial { ~NonTrivial() { } };
static_assert( ! std::is_constructible_v<std::bitset<1>, NonTrivial*> );

The problem is that the bitset(const CharT*) constructor tries to instantiate basic_string_view<NonTrivial> to find its size_type, and that instantiation might ill-formed, e.g. if std::basic_string_view or std::char_traits has a static assert enforcing the requirement for their character type to be sufficiently char-like. 27.1 [strings.general] defines a char-like type as "any non-array trivially copyable standard-layout (6.9.1 [basic.types.general]) type T where is_trivially_default_constructible_v<T> is true."

[2025-08-21; Reflector poll]

Set status to Tentatively Ready after five votes in favour during reflector poll.

Proposed resolution:

This wording is relative to N5008.

  1. Modify 22.9.2.2 [bitset.cons] as indicated:

    
template<class charT>
  constexpr explicit bitset(
    const charT* str,
    typename basic_string_view<charT>::size_type n = basic_string_view<charT>::npos,
    charT zero = charT(’0’),
    charT one = charT(’1’));

    -?- Constraints:

    • is_array_v<charT> is false,
    • is_trivially_copyable_v<charT> is true,
    • is_standard_layout_v<charT> is true, and
    • is_trivially_default_constructible_v<charT> is true.

    -8- Effects: As if by: 

    bitset(n == basic_string_view<charT>::npos
          ? basic_string_view<charT>(str)
          : basic_string_view<charT>(str, n),
       0, n, zero, one)

4300(i). Missing Returns: element in optional<T&>::emplace

Section: 22.5.4.3 [optional.ref.assign] Status: Tentatively Ready Submitter: Giuseppe D'Angelo Opened: 2025-07-15 Last modified: 2025-08-28

Priority: Not Prioritized

View all issues with Tentatively Ready status.

Discussion:

The specification for optional<T&>::emplace in 22.5.4.3 [optional.ref.assign] is not specifying the returned value via a Returns: element; however the function does indeed return something (a T&). Such a Returns: element is there for the primary template's emplace (cf. 22.5.3.4 [optional.assign]).

[2025-08-27; Reflector poll]

Set status to Tentatively Ready after nine votes in favour during reflector poll.

Proposed resolution:

This wording is relative to N5014.

  1. Modify 22.5.4.3 [optional.ref.assign] as indicated:

    template<class U>
  constexpr T& emplace(U&& u) noexcept(is_nothrow_constructible_v<T&, U>);

    -4- Constraints: […]

    -5- Effects: Equivalent to: convert-ref-init-val(std::forward<U>(u)).

    -?- Returns: *val.

4301(i). condition_variable{_any}::wait_{for, until} should take timeout by value

Section: 32.7.4 [thread.condition.condvar], 32.7.5 [thread.condition.condvarany] Status: Tentatively Ready Submitter: Hui Xie Opened: 2025-07-19 Last modified: 2025-08-29

Priority: Not Prioritized

View other active issues in [thread.condition.condvar].

View all other issues in [thread.condition.condvar].

View all issues with Tentatively Ready status.

Discussion:

At the moment, both condition_variable and condition_variable_any's wait_for and wait_until take the timeout time_point/duration by const reference. This can cause surprising behaviour. Given the following example (thanks to Tim Song): 

struct Task {
  system_clock::time_point deadline;
  // stuff
};

std::mutex mtx;
std::condition_variable cv;
std::priority_queue<Task, vector<Task>, CompareDeadlines> queue;

// thread 1
std::unique_lock lck(mtx);
if (queue.empty()) { cv.wait(lck); }
else { cv.wait_until(lck, queue.top().deadline); }

// thread 2
std::lock_guard lck(mtx);
queue.push(/* some task */);
cv.notify_one();

From the user's point of view, it is sufficiently locked on both threads. However, due to the fact that the time_point is taken by reference, and that both libc++ and libstdc++'s implementation will read the value again after waking up, this will read a dangling reference of the time_point.

Another example related to this issue:

We (libc++) recently received a bug report on condition_variable{_any}::wait_{for, until}.

Basically the user claims that these functions take time_point/duration by const reference, if the user modifies the time_point/duration on another thread with the same mutex, they can get unexpected return value for condition_variable, and data race for conditional_variable_any.

Bug report here.

Reproducer (libstdc++ has the same behaviour as ours) on godbolt. 

std::mutex mutex;
std::condition_variable cv;
auto timeout = std::chrono::steady_clock::time_point::max();

// Thread 1:
std::unique_lock lock(mutex);
const auto status = cv.wait_until(lock, timeout);

// Thread 2:
std::unique_lock lock(mutex);
cv.notify_one();
timeout = std::chrono::steady_clock::time_point::min();

So basically the problem was that when we return whether there is no_timeout or timeout at the end of the function, we read the const reference again, which can be changed since the beginning of the function. For condition_variable, it is "unexpected results" according to the user. And in conditional_variable_any, we actually unlock the user lock and acquire our internal lock, then read the input again, so this is actually a data race.

For wait_for, the spec has

Effects: Equivalent to: return wait_until(lock, chrono::steady_clock::now() + rel_time);

So the user can claim our implementation is not conforming because the spec says there needs to be a temporary time_point (now + duration) created and since it should operate on this temporary time_point. There shouldn't be any unexpected behaviour or data race .

For wait_until it is unclear whether the spec has implications that implementations are allowed to read abs_time while the user's lock is unlocked.

it is also unclear if an implementation is allowed to return timeout if cv indeed does not wait longer than the original value of timeout. If it is not allowed, implementations will have to make a local copy of the input rel_time or abs_time, which defeats the purpose of taking arguments by const reference.

For both of the examples, Ville has a great comment in the reflector:

It seems like a whole bag of problems goes away if these functions just take the timeout by value?

libc++ implementers have strong preference just changing the API to take these arguments by value, and it is not an ABI break for us as the function signature has changed.

[2025-08-29; Reflector poll]

Set status to Tentatively Ready after nine votes in favour during reflector poll.

Proposed resolution:

This wording is relative to N5014.

  1. Modify 32.7.4 [thread.condition.condvar] as indicated:

    namespace std {
  class condition_variable {
  public:
    […]
    template<class Predicate>
      void wait(unique_lock<mutex>& lock, Predicate pred);
    template<class Clock, class Duration>
      cv_status wait_until(unique_lock<mutex>& lock,
                           const chrono::time_point<Clock, Duration>& abs_time);
    template<class Clock, class Duration, class Predicate>
      bool wait_until(unique_lock<mutex>& lock,
                      const chrono::time_point<Clock, Duration>& abs_time,
                      Predicate pred);
    template<class Rep, class Period>
      cv_status wait_for(unique_lock<mutex>& lock,
                         const chrono::duration<Rep, Period>& rel_time);
    template<class Rep, class Period, class Predicate>
      bool wait_for(unique_lock<mutex>& lock,
                    const chrono::duration<Rep, Period>& rel_time,
                    Predicate pred);    
    […]
  };
}
    […] 
    template<class Clock, class Duration>
  cv_status wait_until(unique_lock<mutex>& lock,
                       const chrono::time_point<Clock, Duration>& abs_time);

    -17- Preconditions: […]

    […] 

    template<class Rep, class Period>
  cv_status wait_for(unique_lock<mutex>& lock,
                     const chrono::duration<Rep, Period>& rel_time);

    -23- Preconditions: […]

    […] 

    template<class Clock, class Duration, class Predicate>
  bool wait_until(unique_lock<mutex>& lock,
                  const chrono::time_point<Clock, Duration>& abs_time,
                  Predicate pred);

    -29- Preconditions: […]

    […] 

    template<class Rep, class Period, class Predicate>
  bool wait_for(unique_lock<mutex>& lock,
                const chrono::duration<Rep, Period>& rel_time,
                Predicate pred);

    -35- Preconditions: […]

    […]

  2. Modify 32.7.5.1 [thread.condition.condvarany.general] as indicated:

    namespace std {
  class condition_variable_any {
  public:
    […]
    // 32.7.5.2 [thread.condvarany.wait], noninterruptible waits
    template<class Lock>
      void wait(Lock& lock);
    template<class Lock, class Predicate>
      void wait(Lock& lock, Predicate pred);
    
    template<class Lock, class Clock, class Duration>
      cv_status wait_until(Lock& lock, const chrono::time_point<Clock, Duration>& abs_time);
    template<class Lock, class Clock, class Duration, class Predicate>
      bool wait_until(Lock& lock, const chrono::time_point<Clock, Duration>& abs_time,
                      Predicate pred);
    template<class Lock, class Rep, class Period>
      cv_status wait_for(Lock& lock, const chrono::duration<Rep, Period>& rel_time);
    template<class Lock, class Rep, class Period, class Predicate>
      bool wait_for(Lock& lock, const chrono::duration<Rep, Period>& rel_time, Predicate pred);
   
    // 32.7.5.3 [thread.condvarany.intwait], interruptible waits
    template<class Lock, class Predicate>
      bool wait(Lock& lock, stop_token stoken, Predicate pred);
    template<class Lock, class Clock, class Duration, class Predicate>
      bool wait_until(Lock& lock, stop_token stoken,
                      const chrono::time_point<Clock, Duration>& abs_time, Predicate pred);
    template<class Lock, class Rep, class Period, class Predicate>
      bool wait_for(Lock& lock, stop_token stoken,
                    const chrono::duration<Rep, Period>& rel_time, Predicate pred);
  };
}

  3. Modify 32.7.5.2 [thread.condvarany.wait] as indicated:

    […] 
    template<class Lock, class Clock, class Duration>
  cv_status wait_until(Lock& lock, const chrono::time_point<Clock, Duration>& abs_time);

    -6- Effects: […]

    […] 

    template<class Lock, class Rep, class Period>
  cv_status wait_for(Lock& lock, const chrono::duration<Rep, Period>& rel_time);

    -11- Effects: […]

    […] 

    template<class Lock, class Clock, class Duration, class Predicate>
  bool wait_until(Lock& lock, const chrono::time_point<Clock, Duration>& abs_time,
                  Predicate pred);

    -16- Effects: […]

    […] 

    template<class Lock, class Rep, class Period, class Predicate>
  bool wait_for(Lock& lock, const chrono::duration<Rep, Period>& rel_time, Predicate pred);

    -19- Effects: […]

  4. Modify 32.7.5.3 [thread.condvarany.intwait] as indicated:

    […] 
    template<class Lock, class Clock, class Duration, class Predicate>
  bool wait_until(Lock& lock, stop_token stoken,
                  const chrono::time_point<Clock, Duration>& abs_time, Predicate pred);

    -7- Effects: […]

    […] 

    template<class Lock, class Rep, class Period, class Predicate>
  bool wait_for(Lock& lock, stop_token stoken,
                const chrono::duration<Rep, Period>& rel_time, Predicate pred);

    -13- Effects: […]

4318(i). Have hive::erase_if reevaluate end() to avoid UB

Section: 23.3.9.6 [hive.erasure] Status: Tentatively Ready Submitter: Frank Birbacher Opened: 2025-08-16 Last modified: 2025-08-29

Priority: Not Prioritized

View all other issues in [hive.erasure].

View all issues with Tentatively Ready status.

Discussion:

Background: https://github.com/cplusplus/draft/pull/8162

For 23.3.9.6 [hive.erasure] p2, the defining code must not cache the end-iterator. In case the last element of the sequence is removed, the past-the-end iterator will be invalidated. This will trigger UB in the loop condition. Instead, re-evaluate end() each time.

[2025-08-29; Reflector poll]

Set status to Tentatively Ready after five votes in favour during reflector poll.

Proposed resolution:

This wording is relative to N5014.

[Drafting note: There are other ways to fix this code while keeping the caching behaviour, but I don't see any particular reason to do so for the definition of the effects.]

  1. Modify 23.3.9.6 [hive.erasure] as indicated:

    template<class T, class Allocator, class Predicate>
  typename hive<T, Allocator>::size_type
    erase_if(hive<T, Allocator>& c, Predicate pred);

    -2- Effects: Equivalent to: 

    auto original_size = c.size();
for (auto i = c.begin(), last = c.end(); i != lastc.end(); ) {
  if (pred(*i)) {
    i = c.erase(i);
  } else {
    ++i;
  }
}
return original_size - c.size();