-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Predicate: builtins.functionArgsHaveElipses
#7317
Labels
feature
Feature request or proposal
Comments
It is possible to get that information already, but it's a bit hacky 😅 NixOS/nixpkgs#194992 |
This is awesome. I'm so proud of you 😄 |
12 tasks
vkryachko
added a commit
to vkryachko/nix
that referenced
this issue
Sep 10, 2023
This function returns full information about the function, including its formal arguments, whether formals have an ellipse, and optionally the name of the @-pattern argument. Motivation: it's sometimes useful to know if the function uses @-pattern to know if it's safe to call it with callPackage-style, i.e. only passing its "formals" to it. i.e. useful in [254212](NixOS/nixpkgs#254212). A similar change has previously bee proposed as well NixOS#7317
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The name could use some workshopping.
Is your feature request related to a problem? Please describe.
callPackage
style auto-args functions are powerful, but without visibility on the use of elipses - wrapping functions is messy and full of pitfalls.Knowledge of whether a function accepts elipses would allow wrapper routines to know that they should accept and potentially process elipsed args.
Aside from making function wrapping more predictable, this is useful for dynamic type/signature checking, logging, and documentation generation.
Describe the solution you'd like
A simple predicate builtin. The implementation would be nearly identical to
functionArgs
but returns true/false when isformals->elipses
is set.Describe alternatives you've considered
I've used functors to carry meta fields such as
__functionArgs = { foo = true; "_..." = false; }
or_functionMeta.elipsedArgs = true;
I've been able to simplify wrappers in a subset of my own code, but this is tedious and is hardly a good reason to use a functor rather than a function in most cases.Additional
As an extension this might also be used to indicate whether
{x, ...}:
is used to drop fields, or if{x, ...} @ all:
was used to hide them fromfunctionArgs
.The use case there being that for dynamic checking the first category of usage is a form of
intersectAttrs
and the second is an actual variadic function.This has more niche utility but since the fields are just sitting there in C you might as well cover all of the function introspection info. I don't feel particularly strongly about "@" though.
The text was updated successfully, but these errors were encountered: