Skip to content
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

Open
aakropotkin opened this issue Nov 18, 2022 · 3 comments
Open

Predicate: builtins.functionArgsHaveElipses #7317

aakropotkin opened this issue Nov 18, 2022 · 3 comments
Labels
feature Feature request or proposal

Comments

@aakropotkin
Copy link
Contributor

aakropotkin commented Nov 18, 2022

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 from functionArgs.

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.

@aakropotkin aakropotkin added the feature Feature request or proposal label Nov 18, 2022
@infinisil
Copy link
Member

It is possible to get that information already, but it's a bit hacky 😅 NixOS/nixpkgs#194992

@aakropotkin
Copy link
Contributor Author

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 😄

@stale stale bot added the stale label May 21, 2023
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
@anna328p
Copy link
Member

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

@stale stale bot removed the stale label Mar 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature Feature request or proposal
Projects
None yet
Development

No branches or pull requests

3 participants