Extend function reflection

[roberth]

Is your feature request related to a problem? Please describe.

Function reflection is an important part of everyday use of the Nix language, in callPackage and the module system, to improve syntax and to make strict functions lazy.

However, the information is too limited, creating pitfalls that "library" code such as callPackage can not currently compensate.

• Predicate: builtins.functionArgsHaveElipses #7317

Furthermore, it prevents improvements to be made without breaking compatibility:

• Don't require ellipsis in NixOS module definitions. nixpkgs#254212
• Flakes: provide robust access to outPath through new meta argument #8908

Describe the solution you'd like

Two solutions have been already been proposed:

• Add functionInfo builtin #8961
• Flakes: provide robust access to outPath through new meta argument #8908

They could hardly be more different. Open design questions:

• One primop returning attrset or multiple primops?
• Use names that relate to the syntax or names that relate to the semantics?
  • Syntax-based: arg, args, ellipsis, hasArgs
  • Semantics-based: bindsAllAttrs, args, isOpen, strict

Currently implemented by neither:

• Support __functor.

Describe alternatives you've considered

• Reject function reflection altogether. This would make the language more predictable, but that ship has sailed a very long time ago.
• "I want as little reflection as possible, because reflection is complicated and the language should be simple."
  • This suggests a linear relation between the "amount of reflection" and difficulty, which is a simplistic view that's false.
  • Everyday users don't need to interact with this newly exposed info at all. They do get to enjoy more robust reflection.
• "This will cause reflection to be used more often and cause never ending problems. What else do we need to expose next?"
  • More use isn't all that bad, because users are already forced to interact with functionArgs through callPackage and the module system.
  • I believe the proposed interfaces cover all relevant function behaviors, and it's unlikely that we'll need more until perhaps the language itself is extended.

Additional context

Priorities

Add 👍 to issues you find important.

[anna328p]

https://github.com/anna328p/nix-prelude/blob/main/introspection.nix

Most of this is already possible in a hacky way using toXML. I use it in my Nix code.

[roberth]

@infinisil has also written something like that in NixOS/nixpkgs#194992

I suppose it's an extra argument for making this info available: it already is available.
Of course it shouldn't have to be hacky or slow.