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

Closed
MrFlick opened this Issue Nov 22, 2017 · 3 comments

Comments

Projects
None yet
5 participants
@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 from modify not maintaining class for atomic vectors to modify() not maintaining class for atomic vectors Nov 22, 2017

@hadley hadley added bug wip labels Feb 4, 2018

@lionel-

This comment has been minimized.

Member

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

Avoid modify_if()
CRAN version does not preserve type of atomic vectors

tidyverse/purrr#417
tidyverse/purrr#463
@stufield

This comment has been minimized.

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 0.2.4.9000 in the version schema. Am I wrong? Or worse, was it fixed, then reverted? Or should the development version actually read 0.2.5.9000. In which case I humbly withdraw my question ;)

@yutannihilation

This comment has been minimized.

Member

yutannihilation commented Sep 13, 2018

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

v0.2.4...v0.2.5

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment