I completely agree with you, and that was my core idea of the proposal.

I think I stated it before but I'm going to repeat: calling a function
marked as pure that isn't pure is undefined, because the compiler will
assume that it is in fact pure, so it's just going to cache it.

Tymi.

On Wed, 5 Mar 2025, 07:10 Tiago Freire, <tmiguelf_at_[hidden]> wrote:

> 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_at_[hidden]> on behalf
> of Jan Schultke via Std-Proposals <std-proposals_at_[hidden]>
> *Sent:* Wednesday, March 5, 2025 5:34:30 AM
> *To:* Jarrad Waterloo <descender76_at_[hidden]>
> *Cc:* Jan Schultke <janschultke_at_[hidden]>;
> std-proposals_at_[hidden] <std-proposals_at_[hidden]>; Tymi <
> tymi.cpp_at_[hidden]>
> *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_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
>