Proposed resolution:

This wording is relative to N4986.

1. Modify [res.on.data.races] as indicated:

   -2- A C++ standard library function shall not directly or indirectly access objects ([intro.multithread]) accessible by threads other than the current thread unless the objects are accessed directly or indirectly via the function's argumentsparameters, including thisthe object parameter (if any).

   -3- A C++ standard library function shall not directly or indirectly modify objects ([intro.multithread]) accessible by threads other than the current thread unless the objects are accessed directly or indirectly via the function's non-const argumentsparameters, including thisthe object parameter (if any).

   […]

   -5- A C++ standard library function shall not access objects indirectly accessible via its argumentsparameters or via elements of its container argumentsparameters except by invoking functions required by its specification on those container elements.

[ 2025-10-14; Reflector poll ]

Set priority to 3 after reflector poll.

"'non-const parameters' needs to be fixed, this isn't about top-level const, e.g. std::string& is not a const type."

From PR cplusplus/draft#6748 which was closed as non-editorial.

Currently, [res.on.data.races] is talking about arguments and "including this", but this is not a function argument. Moreover, it seems more appropriate to say that a function accesses some object via a parameter.

It might need to be considered whether we should use the more general term "range" instead of "container", which will cover std::span, etc.