In C sure but I am hoping in C++ we will do better.

https://stackoverflow.com/questions/76847905/what-are-the-reproducible-and-unsequenced-attributes-in-c23-and-when-sh

"Effectless restricts what state a function can modify. If any non-local
state is modified, this can only happen through pointers passed to it."
*disallow changing global variables*

"Stateless means that static or thread_local local variables cannot be
*non-const,
and cannot be volatile*."

"Independent means that all calls of the function will see the same values
for global variables, won't change global state, and won't change any state
through pointer parameters."



*can only access const globalsall parameters constno const_castno mutable*

Even if a compiler can't guarantee all of the properties of effectless,
*idempotent*, stateless and independent with varying degrees of success,
what guarantees can be given is of benefit and reduces chances of errors
when implementing these functions.

Reproducible functions should only be able to call other reproducible and
unsequenced functions.
Unsequenced functions should only be able to call other unsequenced
functions.

Compilers need to track these properties for functions similar to how it is
done for constexpr and consteval functions.

In addition to developers promising compilers, developers want promises
from compilers.

Why!

F.8: Prefer pure functions
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#f8-prefer-pure-functions
While you might point out that it says "Enforcement Not possible."
It is really, partially possible given the above checks.

These attributes are similarly related to the following and as such have
similar benefits.

F.15: Prefer simple and conventional ways of passing information
F.16: For “in” parameters, pass cheaply-copied types by value and others by
reference to const
F.17: For “in-out” parameters, pass by reference to non-const
F.20: For “out” output values, prefer return values to output parameters
F.21: To return multiple “out” values, prefer returning a struct
CP.2: Avoid data races

If we had guaranteed results in addition to guaranteed compiler checks then
there would be safety benefits for non constexpr functions which is
something trying to be achieved via various proposals for constexpr.
*Non-transient allocation with std::vector and std::basic_string*
*https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3554r0.html
<https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3554r0.html>*
"Because the function is [[unsequenced]], ... the compiler could even
decide to evaluate square(2) just once at program startup."
If the return was const then that would effectively be an object that is
both memory safe and thread safe or at least a high degree of both.

P.10: Prefer immutable data to mutable data
I.2: Avoid non-const global variables
ES.50: Don’t cast away const
CP.2: Avoid data races
CP.3: Minimize explicit sharing of writable data
Con.1: By default, make objects immutable
Con.2: By default, make member functions const
Con.3: By default, pass pointers and references to consts
Con.4: Use const to define objects with values that do not change after
construction
Con.5: Use constexpr for values that can be computed at compile time












On Tue, Mar 4, 2025 at 10:16 AM Jan Schultke <janschultke_at_[hidden]>
wrote:

> > If this is proposed for C++, can we go ahead and make enforcement
> required.
>
> I'm not sure how you envision that. You can put [[reproducible]] on
> strlen, and this is allowed despite not having a definition of strlen.
> Within the definition of strlen, you could also call other functions
> whose definitions are not visible in the current TU, but that's
> perfectly fine.
>
> [[reproducible]] and [[unsequenced]] are highly unsafe,
> optimization-motivated, developer promises to the compiler.
>