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

Force arguments that are used in closures #2807

Merged
merged 1 commit into from Sep 15, 2018
Merged

Force arguments that are used in closures #2807

merged 1 commit into from Sep 15, 2018

Conversation

@krlmlr
Copy link
Member

@krlmlr krlmlr commented Aug 7, 2018

The reprex below triggered the investigation that led to possible instances where "brittle closures" are returned. I have no idea if the other instances I found have an effect, but it feels like good practice to force arguments that are used by closures.

Happy to add tests as necessary.

library(tidyverse)

scale <- c("red", "green", "blue")

p <-
  ggplot(iris, aes(Petal.Length, Petal.Width, color = Species)) +
  geom_point() +
  scale_color_manual(values = unlist(scale), labels = levels(iris$Species))

scale <- scale[-1]

p

Created on 2018-08-07 by the reprex package (v0.2.0).

hadley
hadley approved these changes Sep 12, 2018
Copy link
Member

@hadley hadley left a comment

No need for tests, I think.

@krlmlr krlmlr changed the title WIP: Force arguments that are used in closures Force arguments that are used in closures Sep 12, 2018
@clauswilke clauswilke mentioned this pull request Sep 12, 2018
25 tasks
@clauswilke
Copy link
Member

@clauswilke clauswilke commented Sep 13, 2018

@krlmlr Do you want to look whether there are any other such cases or do we leave it as it currently is for this PR?

@@ -117,7 +117,10 @@ plot_dim <- function(dim = c(NA, NA), scale = 1, units = c("in", "cm", "mm"),
dim
}

plot_dev <- function(device, filename, dpi = 300) {
plot_dev <- function(device, filename = NULL, dpi = 300) {
Copy link
Member

@clauswilke clauswilke Sep 13, 2018

For my own education, could you explain why we now need filename = NULL here but in some other cases (e.g., make_summary_fun()) we don't need to add a default?

Copy link
Member Author

@krlmlr krlmlr Sep 15, 2018

The default doesn't make sense there to me, the function needs arguments or fails. But e.g. manual_scale() could use a better error message.

@krlmlr
Copy link
Member Author

@krlmlr krlmlr commented Sep 15, 2018

This PR contains all instances I've found, looking for ^ +function in the code and ignoring false positives. The initial comment describes just one instance. This is good to go from my end.

@krlmlr
Copy link
Member Author

@krlmlr krlmlr commented Sep 15, 2018

NEWS entry:

  • Functions that generate other functions (closures) now force the arguments that are used from the generated functions, to avoid hard-to-catch errors (#2807, @krlmlr).

@hadley
Copy link
Member

@hadley hadley commented Sep 15, 2018

I don't think this warrants a news bullet as the chance of it affecting user code is extremely small.

@krlmlr
Copy link
Member Author

@krlmlr krlmlr commented Sep 15, 2018

My example came from user code, though. I guess it would fit in a change log but not in NEWS.

@clauswilke
Copy link
Member

@clauswilke clauswilke commented Sep 15, 2018

Thanks!

@clauswilke clauswilke merged commit a4d7d81 into tidyverse:master Sep 15, 2018
4 checks passed
@krlmlr krlmlr deleted the b-force-gen branch Sep 17, 2018
@lock
Copy link

@lock lock bot commented Mar 16, 2019

This old issue has been automatically locked. If you believe you have found a related problem, please file a new issue (with reprex) and link to this issue. https://reprex.tidyverse.org/

@lock lock bot locked and limited conversation to collaborators Mar 16, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

3 participants