The drawback of builtins.functionArgs is that when we write {lib, pkgs, ...}@args: { x = args.x}, if the function is called by callPackage or a similar mechanism that uses builtins.functionArgs, we actually cannot retrieve the x field as expected.
The difficulty in removing builtins.functionArgs lies in the fact that this built-in function is heavy used by callPackage.
A possible solution is to add ... at the end of the parameter list of the code for all packages, like {lib, pkgs, ...}: {}, to avoid relying on builtins.functionArgs. I’m not sure if this is feasible or what potential issues might arise, so I’m initiating this discussion.
I’d rather like to question the need for individual packages as function parameters; obviating callPackage entirely. Why couldn’t we just pass all pkgs?
The only thing it really affords us is to override the meaning of package names but the same could be achieved using pkgs // { foo = ...; } or overlays/extensions.
Short answer: no. Removing a non-experimental builtin supported since nixpkgs/lib/minver.nix (2.3) breaks expressions. Makes talk of reproducibility kind of moot.
Long answer: functionArgs is an ugly capability that turns nice and simple laws into mere rules of thumb. One rule comes to mind, but there’s probably a lot more: eta expansion isn’t a guaranteed correct refactor: functionArgs (x: f x) is {} and often not equal to functionArgs f.
So while we can’t remove it, we can choose not to use it.
I’ve played with that in Single package fixpoint by roberth · Pull Request #296769 · NixOS/nixpkgs · GitHub, but I ended up using it anyway, because otherwise more boilerplate would be needed. I think the main thing that PR demonstrated wrt functionArgs is that we can have an incremental migration path to a different solution/solutions that solve the flaws of callPackage.
In package.nix files, you’d pick a new solutions like this:
If we’re redesigning callPackage/mkDerivation, we don’t need splicing and shouldn’t propagate it. I link to simpler, saner cross-compilation · Issue #227327 · NixOS/nixpkgs · GitHub all the time these days, but it really is the ideal we should be approaching, and would certainly not require any builtins.functionArgs.