# NULL vs zero-length vectors #24

Open
opened this issue Oct 10, 2018 · 5 comments

Member

### hadley commented Oct 10, 2018

 For vectorised arguments I think we should consistently treat NULL in the same way as if the argument had not been supplied. This is symmetric with our use of `NULL` for the default value of optional arguments that need complex calculations. ```library(vctrs) vec_c(TRUE, double()) #> [1] 1 vec_c(TRUE, NULL) #> [1] TRUE # Same as vec_c(TRUE, ) #> [1] TRUE # Same as vec_c(TRUE) #> [1] TRUE```
Member Author

### hadley commented Oct 10, 2018 • edited

 For glue this would imply that the following calls should be identical: ```glue::glue("{a}: {b}", a = 1:2) #> Error in eval(parse(text = text, keep.source = FALSE), envir): object 'b' not found glue::glue("{a}: {b}", a = 1:2, b = ) #> Error in eval(parse(text = text, keep.source = FALSE), envir): argument is missing, with no default glue::glue("{a}: {b}", a = 1:2, b = NULL)``` And for purrr: ```str(purrr::pmap(rlang::list2(1, 2), list)) #> List of 1 #> \$ :List of 2 #> ..\$ : num 1 #> ..\$ : num 2 str(purrr::pmap(rlang::list2(1, 2, ), list)) #> List of 1 #> \$ :List of 2 #> ..\$ : num 1 #> ..\$ : num 2 str(purrr::pmap(rlang::list2(1, 2, NULL), list)) #> list()``` For tibble: ```tibble::tibble(x = 1:2) #> # A tibble: 2 x 1 #> x #> #> 1 1 #> 2 2 tibble::tibble(x = 1:2, y = NULL) #> Error: Column `y` must be a 1d atomic vector or a list # vs tibble::tibble(x = 1:2, y = integer()) #> Error: Column `y` must be length 1 or 2, not 0```
referenced this issue Nov 9, 2018
Member Author

### hadley commented Nov 28, 2018

 Also comes up in `pluck()`
referenced this issue Jan 5, 2019
added the label Feb 19, 2019
Member Author

### hadley commented Feb 19, 2019

 Connected to #13
referenced this issue Feb 20, 2019
Member

### krlmlr commented Feb 22, 2019

 Is the current behavior of `mutate(iris, Petal.Width = NULL)` consistent with that description? (I admit I sometimes use it to say "I don't care if this column exists or not, just get rid of it", but it doesn't seem completely right.)
Member Author

### hadley commented May 28, 2019 • edited

 @krlmlr I think that's a special case where it's ok to have different behaviour. And now implemented in `tidyr::expand_grid()`. This ensures that for vector inputs, `vec_size(expand_grid(x1, x2, ..., xn))` = `vec_size(x1) * vec_size(x2) * ... * vec_size(xn)`.
referenced this issue Sep 11, 2019