I would rather we had :doc without this. I'm not eager to have more builtin.unsafe*, though pure eval mode does help mitigate.

I would rather we had :doc without this. I'm not eager to have more builtin.unsafe*, though pure eval mode does help mitigate.

I don't think pure eval mode disallows any of the unsafe builtins.

Do we need to restrict this to lambdas? We should have position information for most Nix expressions.

I believe that the reason it's called unsafe is because it basically guarantees that your function is impure as it then starts depending on the exact source making the derivation. Perhaps it should be named differently, but then it's inconsistent. I want this functionality for debugging mostly, anyway, and I can see it being potentially useful outside of the REPL in tracing or other places.

I do not believe it is a risk for restricted evaluation mode because you'd have to first evaluate the file that's not in the Nix store before you get any information on it.

As for restricting it to lambdas, that's a fantastic question I do not know the answer to and I was mostly staring at lambdas too hard to notice.

@matthewbauer I looked into it. If we just have the value, it is not possible to get the position of things other than lambdas. See src/libexpr/value.hh in struct Value: the only value types that appear to have any metadata to speak of in there are lambdas.

It might be possible to take advantage of lazy evaluation in some way to achieve this, since perhaps we might have the appropriate context still existing prior to the forceValue call, but I don't know enough about Nix internals to implement this idea.

I have also made it so :doc can be implemented directly as a Nix plugin with #3934.

If there isn't any other proposed use of unsafeGetLambdaPos besides hypothetically building an inferior version of the now-existing nix-doc nix plugin that just got into nixpkgs (that uses essentially this code but natively from C++ and does the docs stuff in-process), I think we should abandon this PR.