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

modify() not maintaining class for atomic vectors #417

MrFlick opened this issue Nov 22, 2017 · 3 comments

modify() not maintaining class for atomic vectors #417

MrFlick opened this issue Nov 22, 2017 · 3 comments


Copy link

@MrFlick MrFlick commented Nov 22, 2017

The documentation for modify says that the .x parameter is "A list or atomic vector." and the "Value" section says that the functions will return "An object the same class as .x" However for atomic vectors, it seems to return a list, and not a vector of the same class as .x.

x <- c("a","b","c","d","e")
y <- c(1, 2, 3, 4, 5)
z <- c(T, F, T, F, T)

class(modify(x,function(x) "k"))
# [1] "list"      ## not class(x)

class(modify(y,function(x) 10))
# [1] "list"     ## not class(y)

class(modify_if(x, z, function(x) "k"))
# [1] "list"     ## not class(x)

class(modify_if(y, z, function(x) x+10))
# [1] "list"     ## not class(y)

The help page also says that modify() is basically the same as x[] <- map(x, .f) and ifs that's the case i'd expect map() to return a list, But even on the ?map help page it calls out: "See the modify() family for versions that return an object of the same type as the input."

Tested with purrr_0.2.4 and R version 3.4.1 (2017-06-30)

@MrFlick MrFlick changed the title modify not maintaining class for atomic vectors modify() not maintaining class for atomic vectors Nov 22, 2017
@hadley hadley added bug wip labels Feb 4, 2018
Copy link

@lionel- lionel- commented Feb 14, 2018

Should be fixed by #463

@lionel- lionel- closed this Feb 14, 2018
jennybc added a commit to tidyverse/googlesheets4 that referenced this issue Apr 9, 2018
CRAN version does not preserve type of atomic vectors

Copy link

@stufield stufield commented Sep 13, 2018

Question: has this issue been resolved? I stubbed my toe on it today using the CRAN version purrr_0.2.5 and the list conversion is still happening. I reverted to the dev version, which appears to be purrr_0.2.4.9000, and it's fixed there. My confusion arises from my assumption that 0.2.5 comes after in the version schema. Am I wrong? Or worse, was it fixed, then reverted? Or should the development version actually read In which case I humbly withdraw my question ;)

Copy link

@yutannihilation yutannihilation commented Sep 13, 2018

It seems some commits included in v0.2.5 are forgot to be merged into master...


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants