On 2026-09-26 09:48, Larry Garfield wrote:
The OP mentioned possible optimizations or inlining or things like that. At
least some of those would need to be included initially to justify the RFC.
>
I'm also keen on explicit purity if there is some actual benefit (e.g.
memoisation, inlining, partial evaluation) to making the assertion.
The other catch is that, as Marco notes, purity is not always trivial to
discover. Especially when passing around objects, if you call a method on the
object, it MIGHT mutate something? Who knows? So defining precisely what
we're able to enforce would be important, too.
(As a simple example of not-pure-after-all, strval(1/7) is affected by
the precision ini setting.)
If it is something that is being enforced then it's something that could
potentially be checked during compilation anyway (as soon as an impure
operation is encountered it poisons the function (and, transitively, any
callers to the function)), and so the assertion wouldn't be needed.
