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

Should env_ functions be internally generic #427

Closed
hadley opened this issue Feb 28, 2018 · 2 comments
Closed

Should env_ functions be internally generic #427

hadley opened this issue Feb 28, 2018 · 2 comments
Labels
env
Milestone

Comments

@hadley
Copy link
Member

@hadley hadley commented Feb 28, 2018

Not the parent of that environment.

library(rlang)

f <- function() {}
env_parent(f)
#> <environment: package:rlang>
#> attr(,"name")
#> [1] "package:rlang"
#> attr(,"path")
#> [1] "/Users/hadley/R/rlang"

Created on 2018-02-28 by the reprex package
(0.1.1.9000)
.

@hadley hadley added the env label Feb 28, 2018
@lionel-
Copy link
Member

@lionel- lionel- commented Mar 8, 2018

Should we deprecate the internal genericity of env_ functions?

@hadley hadley changed the title env_parent should return the "enclosing" environment of a function Should env_ functions be internally generic Mar 8, 2018
@hadley
Copy link
Member Author

@hadley hadley commented Mar 8, 2018

I renamed the title of this issue. Another typo that this behaviour makes confusing:

library(rlang)
env_bind(env, x = 1)
#> Error in base::assign(nm, data[[nm]], envir = env_): cannot add bindings to a locked environment

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

@lionel- lionel- added this to the 0.3.0 milestone Mar 8, 2018
@lionel- lionel- closed this in 72fb6e3 Sep 20, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants