I think it only makes sense when you have a forward declaration but no visible definition.
Warning would be issued in the translation unit that has both the forward declaration with [[pure]] and an impure definition. Although that last part might be problematic as a function might still be pure and unmarked, which would prevent a function calling it from being marked pure even though the programmer might know that it is.
So that warning mechanism needs further explanation.

________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]pp.org> on behalf of JJ Marr via Std-Proposals <std-proposals_at_[hidden]>
Sent: Tuesday, March 4, 2025 8:16:06 AM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: JJ Marr <jjmarr_at_[hidden]>; Tymi <tymi.cpp_at_[hidden]>
Subject: Re: [std-proposals] [[pure]] attribute


Shouldn't it be "ill-formed, no diagnostic required"? If compilers are required to emit a warning when [[pure]] is misapplied, then we cannot use [[pure]] when the compiler is unable to determine that the function is pure (because otherwise the compiler might fail to emit a warning when one is required). That would defeat the purpose of this proposal.

On Tue, Mar 4, 2025, 2:07 a.m. Tymi via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> wrote:
Some functions have no side effects, and while they can be often optimised, the compiler is not aware of that.
Consider this example:
```cpp
template <std::arithmetic T> constexpr T(const T a, const T b) { return a + b; }
```
That function could be declared as pure, or in other words, produces no side effects.

I think this is a great way to optimise frequent calls, such as a pure function's result can be cached for the same arguments provided.

Diagnostics: if a pure function has side effects, the compiler shall issue a warning and calling that function is undefined.

pure member function shall be declared as const, otherwise, the program is ill-formed.

--
Std-Proposals mailing list
Std-Proposals_at_[hidden]<mailto:Std-Proposals_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals