env_set ?

[hadley]

env_set <- function(env, nm, value) {

}

Obviously you can achieve the same thing with env_bind() but it has a nice symmetry with env_get() and avoids tidyeval in some common scenarios (i.e. using an env as a cache)

[lionel-]

Also env_reset() as a <<- equivalent that would issue an error if nm can't be found? Instead of binding in the current env like <<-.

[hadley]

Maybe env_override()? I think re-set is too easily confused with reset.

[lionel-]

I was thinking that reset (not re-set) also makes sense here.

How about this: introduce a new prefix for the inheriting cases. We'd have scope_get() and scope_has() as inheriting env_get() and env_has(). And scope_set() could have override, reset or create argument set to FALSE by default.

We get two families for these very different semantics, but it's easy to figure out the function names because they are just prefix variants.

[hadley]

To me, reseting implies returning to an initial value.

Do we really need scope_ prefixes? It doesn't feel like inherits = TRUE is used that often. It seems too dilutive of the API relative to the pay off.

[lionel-]

To me, reseting implies returning to an initial value.

oh right.

About the prefixes, I've been thinking we need a specific set of functions since I started working on this env_ API because the semantics are so different: working with an environment as a container versus working with an environment as a scope.

[lionel-]

Another advantage of having separate families is that the reasonable default values of arguments might change depending on whether you're working with a scope or an environment.

For instance env_set() should have create = TRUE by default, but scope_set() should probably have create = FALSE.