This is not correct behavior, as there are primops (like builtins.fetchGit) that take an attrset of a certain shape, which can't be verified with this.

Oh, right, I did not think about such primops.
However, it seems that most of primops that accept attrset as one of their formal argumentrs (from what I saw, this includes prim_fetchMercurial, prim_fetchTree, prim_fetchurl, prim_fetchTarball, prim_fetchGit, and others) are polymorphic and accepts other types (such as strings). Such a "polymorphic" function f in nix would looks like x: if builtins.typeOf x = "set" then ... else ..., and then functionArgs f yields {}.

Therefore, what should be the correct behavior for such "polymorphic" primops?

I found prim_genericClosure that takes an attrset and nothing else, I guess there's a couple more. But then, what is the good strategy? Decide such primops are rare and add manually cases in functionArgs would be rather ugly. Another option would I guess be to change addPrimOp so that instead of simply taking an arity, it takes a list of maybe attr names (say list (maybe (list name))), and reflect that change in PrimOp struct.

This would allow functionArgs to have the proper behaviour for both primops and primops partial applications.

Not too sure it's a good idea though.

oh huh, i was not aware you could builtins.fetch* strings. huh

I think this change is correct and should be merged because:

• The semantics of builtins.functionArgs are that any arguments it returns have to be accepted by the function, but that doesn't mean that other arguments can't be accepted. So returning {} for primops is an entirely consistent and safe behavior
• In fact, primops are implemented very much like args: ... args.foo ... Nix functions, taking attributes from args whenever they need. And builtins.functionArgs for such Nix functions also obviously returns {}
• In addition, the current behavior of builtins.isFunction returning true for primops, yet builtins.functionArgs failing is very inconsistent

All this stuff is wack, but @infinisil does make sense. And if functionArgs is a conservative approximation, I guess we can give it more info about primops later?

Thanks, makes sense!