Yes, I saw those examples.   Error states, FP round-off errors and so on are details, which could be prohibited or better defined for pure functions.   If we fully embrace pure functions, we would provide the whole state as a read-only value parameter.   The possibly new modified state would be output together with the result.   A push_back on a vector would not modfiy the vector in-place, but output the appended vector as a copy.   Pure functions can improve the performance (by caching, by better parallelization, by pipelining computations), but they also can worsen it with the copy operations. The hardware can support it to a certain degree with copy-on-write COW mechanisms.   Programs could be made safer or more bug-free as certain classes of errors are less likely.   In the end we would have a stronger functional programming paradigm inside C++.   I agree: There are probably people very experienced in C++ (like compiler writers) and functional languages (and their performant implementation and use for general real-world applications), who could advise.     -----Ursprüngliche Nachricht----- Von:hans.gustav.aberg_at_[hidden] Gesendet:Mi 05.03.2025 14:40 Betreff:Re: [std-proposals] [[pure]] attribute An:std-proposals_at_[hidden]; CC:Sebastian Wittmeier <wittmeier_at_[hidden]>; It is hard to define what is pure, as the computations may make various state modifications that cancel or are not semantically essential. This cancellation that may occur is what leads to the undecidability. If a function calls an impure function, but only uses pure values, is that function pure? Some examples of non-essential impurities were given in this thread: modifications of error states, floating-point round-off errors due to caching. If you were to optimize, do some rearranging of code, say, then they should be considered pure, I would think. It would be best to ask compiler writers what they think.