Revised 2026-04-20 at 17:40:27 UTC

Tentative Issues

4417(i). views::indices is underconstrained

Section: 25.6.4.1 [range.iota.overview] Status: Tentatively NAD Submitter: Hewill Kang Opened: 2025-10-15 Last modified: 2026-01-16

Priority: Not Prioritized

View all other issues in [range.iota.overview].

View all issues with Tentatively NAD status.

Discussion:

Whether an integer-class type satisfies weakly_incrementable is unspecified according to 25.6.4.2 [range.iota.view]. For example, the library may provide a member type alias difference_type for the integer-class type to make it weakly_incrementable, or not.

If the latter, then views::iota(integer-class-type(0)) is always ill-formed because iota_view<W, Bound> requires W to be weakly_incrementable.

However, unlike views::iota, views::indices unconditionally accepts integer-class types, which will lead to a hard error in the function body if the integer-class type is not weakly_incrementable, which is true for both libstdc++ and MSVC-STL.

[2026-01-16; Reflector poll. Status → Tentatively NAD.]

"This is implied by the expression-equivalence."

Proposed resolution:

This wording is relative to N5014.

  1. Modify 25.6.4.1 [range.iota.overview] as indicated:

    -4- The name views::indices denotes a customization point object (16.3.3.3.5 [customization.point.object]). Given subexpression E, let T be remove_cvref_t<decltype((E))>. views::indices(E) is expression-equivalent to views::iota(T(0), E) if is-integer-like<T> is true and T models weakly_incrementable, and ill-formed otherwise.

4475(i). The description to single total order in [thread.mutex.requirements.mutex.general] is hollow

Section: 32.6.4.2.1 [thread.mutex.requirements.mutex.general] Status: Tentatively NAD Submitter: jim x Opened: 2025-11-14 Last modified: 2026-01-16

Priority: Not Prioritized

View other active issues in [thread.mutex.requirements.mutex.general].

View all other issues in [thread.mutex.requirements.mutex.general].

View all issues with Tentatively NAD status.

Discussion:

32.6.4.2.1 [thread.mutex.requirements.mutex.general] p4 says:

For purposes of determining the existence of a data race, these behave as atomic operations (6.10.2 [intro.multithread]). The lock and unlock operations on a single mutex appears to occur in a single total order.

Even for atomic operations, the precondition for ordering them in a single total order is that they must be memory_order::seq_cst operations, such that we can form the total order to reason.

Put aside the fact that we impose the preconditions on unlock and lock. Is this a possible total order if lock reads unlock_1, but there is a unlock_2 between them

unlock_1 < unlock_2 < lock

First, although we have said that lock and unlock operations behave as atomic operations, and lock reads unlock_1, meaning that unlock_1 is coherence-ordered before lock, however, we don't specify that they are memory_order::seq_cst operations, so 32.5.4 [atomics.order] p4 doesn't apply here

Second, for every pair of atomic operations A and B on an object M, where A is coherence-ordered before B, the following four conditions are required to be satisfied by S:

So, it is not helpful to decide that unlock_1 precedes lock in a single total order. Similarly, excluding unlock_1 < unlock_2 < lock is not possible.

Suggested resolution:

The lock and unlock operations on a single mutex appears to occur in a single total order; for this purpose, these operations are considered as memory_order::seq_cst operations

[2026-01-16; Reflector poll. Status → Tentatively NAD.]

For atomic objects, the modification order is already a single total order, seq_cst or not. This isn't a useful change.

Proposed resolution:

This wording is relative to N5014.

  1. Modify 32.6.4.2.1 [thread.mutex.requirements.mutex.general] as indicated:

    -4- The implementation provides lock and unlock operations, as described below. For purposes of determining the existence of a data race, these behave as atomic operations (6.10.2 [intro.multithread]). The lock and unlock operations on a single mutex appears to occur in a single total order; for this purpose, these operations are considered as memory_order::seq_cst operations.

4494(i). Add consteval to std::meta::exception defaulted member functions

Section: 21.4.4 [meta.reflection.exception] Status: Tentatively NAD Submitter: Marek Polacek Opened: 2025-12-16 Last modified: 2026-01-28

Priority: Not Prioritized

View other active issues in [meta.reflection.exception].

View all other issues in [meta.reflection.exception].

View all issues with Tentatively NAD status.

Discussion:

CWG 3115 states that every function of consteval-only type shall be an immediate function. This caused a problem for std::meta::exception::what() which was marked constexpr but not consteval. To be able to mark it consteval, we had to tweak the rules about overriding by a consteval virtual function (CWG 3117).

But 21.4.4 [meta.reflection.exception] still defines std::meta::exception such that it contains these defaulted special member functions: 

exception(const exception&) = default;
exception(exception&&) = default;

exception& operator=(const exception&) = default;
exception& operator=(exception&&) = default;

which aren't consteval (and since they're not templates, they won't be promoted to consteval as per P2564). I propose to make the four functions consteval: 

consteval exception(const exception&) = default;
consteval exception(exception&&) = default;

consteval exception& operator=(const exception&) = default;
consteval exception& operator=(exception&&) = default;

[2026-01-28; Reflector poll. Status → Tentatively NAD.]

The second change in CWG 3115 fixes this.

Proposed resolution:

This wording is relative to N5032.

  1. Modify 21.4.4 [meta.reflection.exception] as indicated:

    namespace std::meta {
  class exception : public std::exception {
  private:
    optional<string> what_;  // exposition only
    u8string u8what_;        // exposition only
    info from_;              // exposition only
    source_location where_;  // exposition only
  public:
    consteval exception(u8string_view what, info from,
                        source_location where = source_location::current()) noexcept;
                        
    consteval exception(string_view what, info from,
                        source_location where = source_location::current()) noexcept;
                        
    consteval exception(const exception&) = default;
    consteval exception(exception&&) = default;
    
    consteval exception& operator=(const exception&) = default;
    consteval exception& operator=(exception&&) = default;
    
    constexpr const char* what() const noexcept override;
    consteval u8string_view u8what() const noexcept;
    consteval info from() const noexcept;
    consteval source_location where() const noexcept;
  };
}

4542(i). Resuming a coroutine on a different execution agent that is an instance of a std::thread is underspecified

Section: 17.13.4.6 [coroutine.handle.resumption] Status: Tentatively NAD Submitter: jim x Opened: 2026-03-11 Last modified: 2026-04-13

Priority: Not Prioritized

View all issues with Tentatively NAD status.

Discussion:

Consider the following example: 

#include <atomic>
#include <cassert>
#include <coroutine>
#include <thread>

std::atomic<bool> flag = false;
int global = 0;

struct Task 
{
  struct promise_type 
  {
    Task get_return_object() {
      return {std::coroutine_handle<promise_type>::from_promise(*this)};
    }
    std::suspend_never initial_suspend() { return {}; }
    std::suspend_never final_suspend() noexcept { return {}; }
    void return_void() {}
    void unhandled_exception() {}
  };

  std::coroutine_handle<promise_type> handle;

  Task(std::coroutine_handle<promise_type> h) : handle(h) {}
  ~Task() {}
};

struct SuspendOnce 
{
  bool suspended = false;
  bool await_ready() { return suspended; }
  void await_suspend(std::coroutine_handle<>) { suspended = true; }
  void await_resume() {}
};

Task my_coroutine() {
  co_await SuspendOnce{};
  flag.store(true, std::memory_order::release); // #2
}

auto t1 = std::thread([]() {
  while (!flag.load(std::memory_order::acquire)); //#3
  assert(global == 1); // #4
});

int main() {
  auto task = my_coroutine();
  auto& h = task.handle;
  auto t2 = std::thread([&]() {
    global = 1; // #1
    h.resume();
  });
  t2.join();
  t1.join();
}

17.13.4.6 [coroutine.handle.resumption] p1 says:

Resuming a coroutine via resume, operator(), or destroy on an execution agent other than the one on which it was suspended has implementation-defined behavior unless each execution agent either is an instance of std::thread or std::jthread, or is the thread that executes main.

The wording doesn't specify the behavior for the latter case. We want #1 to be sequenced before #2.

The sequenced-before is described in terms of two evaluations that are both executed by a single thread. The coroutine is initially executed in the main thread; however, it's resumed in a different thread. The first paragraph doesn't specify the specific behavior; it only says the behavior is implementation-defined if the different execution agent is not an instance of std::thread or std::jthread, or is the thread that executes main.

[2026-04-13; Reflector poll. Status → Tentatively NAD.]

The point of paragraph 1 is to say when paragraphs 2-5 don't apply (e.g. if you suspend on the main thread and resume on a fiber). If you don't do anything like that, then paragraphs 2-5 describe the effects.

Proposed resolution:

This wording is relative to N5032.

  1. Modify 17.13.4.6 [coroutine.handle.resumption] as indicated:

    -1- Resuming a coroutine via resume, operator(), or destroy on an execution agent other than the one on which it was suspended has implementation-defined behavior unless each execution agent either is an instance of std::thread or std::jthread, or is the thread that executes main. Otherwise, the execution of the coroutine is resumed, or the coroutine is destroyed, on the execution agent on which the corresponding member function is invoked.

    […]