I think that to a certain extent the user who is doing the markings should be responsible for doing it right.

What we want is for a way to cache values instead of wasting time with expensive but deterministic computations. And we already know that the compiler can't always validate if a function is or isn't "pure".

The compiler is just going to have to trust that the developer did the right thing, and if they didn't the compiler is still going to be able to generate some code and it is going to be their problem that the program does the wrong thing.

It would be nice if the compiler could warn if they know for sure that the user did the wrong thing, but it doesn't need to cover every corner case and be a perfect 100% detection. (if it could do that, the classification probably wouldn't be needed).


From: Std-Proposals <std-proposals-bounces@lists.isocpp.org> on behalf of Jan Schultke via Std-Proposals <std-proposals@lists.isocpp.org>
Sent: Wednesday, March 5, 2025 5:34:30 AM
To: Jarrad Waterloo <descender76@gmail.com>
Cc: Jan Schultke <janschultke@googlemail.com>; std-proposals@lists.isocpp.org <std-proposals@lists.isocpp.org>; Tymi <tymi.cpp@gmail.com>
Subject: Re: [std-proposals] [[pure]] attribute

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

Please no. Contrary to intuition, "reproducible" is not a property
that can simply be combined bottom-up.

For example, std::exchange is not reproducible, but a reproducible
function could make use of it. Since [[unsequenced]] is even stricter,
the same applies. Similarly, std::swap for an array of ints is
reproducible, but std::swap isn't.

On that note, C++ also faces the unique problem that only some
specializations of function templates are [[reproducible]] or
[[unsequenced]]. SInce C doesn't have generics, it doesn't have this
problem. For example, std::sort for any standard library container is
reproducible, but not for user-defined types that could do
god-knows-what when swapped.
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals