-
Notifications
You must be signed in to change notification settings - Fork 24
Support if_else() with named arguments #822
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
base: main
Are you sure you want to change the base?
Conversation
Co-authored-by: krlmlr <[email protected]>
Co-authored-by: krlmlr <[email protected]>
|
@copilot: All function calls should be treated with |
Co-authored-by: krlmlr <[email protected]>
Co-authored-by: krlmlr <[email protected]>
Implemented in aa90b65. Added
Aggregation functions ( |
krlmlr
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
rel_get_call_match_def()is not needed, we know the package and can look up the function definitions directly.- Move the logic of handling primitives early. Rely only on named argument lookup after matching.
Co-authored-by: krlmlr <[email protected]>
Co-authored-by: krlmlr <[email protected]>
Addressed in f3d1dce. Removed |
if_else()with named arguments throws errorsif_elsewith named argumentscall_match()to all function callsrel_get_call_match_def()function, use dynamic function lookup from package namespacerel_primitivesvector to identify operators and functions that don't needcall_match()call_match()generically usingget0(name, envir = asNamespace(pkg))for non-primitive functionsOriginal prompt
This section details on the original issue you should resolve
<issue_title>
if_else()with named arguments throws errors</issue_title><issue_description>When using
if_else()with named arguments, there's a fall back to dplyr, but when using the function directly without named arguments it works well with duckplyr.I wasn't expecting the fall back in to dplry this case. I didn't test for other functions.
Is this the expected behavior?
Example
Created on 2025-07-11 with reprex v2.1.1
Session info