Function attribute best practices

[H. S. Teoh]

On Mon, Sep 12, 2022 at 02:29:58PM -0400, Steven Schveighoffer via Digitalmars-d-learn wrote:
[...]
> If your intent is to *enforce* pure functions only, then that's what
> you do.  If your intent instead is to ensure that given proper
> parameters, the function will be pure, then the answer is to unittest.
> 
> I will say, sometimes this gets really annoying. Like if the unittest
> fails, you get very little information about *why* it's not working.
> 
> i.e. you expect the inference to be pure, but it's not. All you get is
> "impure unittest can't call impure function foo(...)". Figuring out
> the misinference cause is a chore today. I wish it would be easier.
[...]

+1, we need better diagnostics around this.

I wonder if it could be done this way: whenever the compiler infers
attributes for some function F, along with the inferred attributes it
also attaches a list of locations where each attribute was excluded from
the inference. For example, if F was inferred as impure, the compiler
would also keep a reference to the first line where an impure operation
was performed in F.  Whenever pure code tries to call F, the compiler
would print out this reference (file + line + column) along with the
error message.  I.e., "pure function G cannot call impure function F
because impure was inferred from line 1234 in F."

Obviously, this applies only to functions with inferred attributes; if
the attribute was explicitly in the code, then there's nothing else to
say.  Since functions with inferred attributes always must have their
bodies accessible (otherwise inference cannot be done), it's guaranteed
that the aforementioned reference can always be found.

//

In the meantime, my usual approach to debugging this sort of problem is
to explicitly (temporarily) mark the target function pure, and recompile
to find out what in the function made it impure. If it's a call to
another inferred function, then mark *that* function pure too, and
recompile, etc., until I arrive at the statement that first made it
impure.  This doesn't always work, though.  Sometimes forcefully marking
something pure will break the compile in other places, making it a pain
to debug (usually involving making a local copy of the function and
redirecting calls to/from it).

The compiler really should be giving us this information rather than
making us figure it out ourselves.


T

-- 
Ignorance is bliss... until you suffer the consequences!