dplyr 1.1.4 breaks on empty dataframes constructed from matrices

[john-b-edwards]

Previous versions of dplyr would allow you to manipulate empty dataframes that had been constructed from empty matrices, e.g.

packageurl <- "https://cran.r-project.org/src/contrib/Archive/dplyr/dplyr_1.1.3.tar.gz"
install.packages(packageurl, repos=NULL, type="source")
#> Installing package into 'C:/Users/edwar/Documents/R/win-library/4.1'
#> (as 'lib' is unspecified)
packageVersion('dplyr')
#> [1] '1.1.3'
as.data.frame(matrix(nrow = 0, ncol = 0)) |> dplyr::slice(1)
#> data frame with 0 columns and 0 rows

In dplyr 1.1.4, this code causes an internal error:

packageurl <- "https://cran.r-project.org/src/contrib/dplyr_1.1.4.tar.gz"
install.packages(packageurl, repos=NULL, type="source")
#> Installing package into 'C:/Users/edwar/Documents/R/win-library/4.1'
#> (as 'lib' is unspecified)
packageVersion('dplyr')
#> [1] '1.1.4'
as.data.frame(matrix(nrow = 0, ncol = 0)) |> dplyr::slice(1)
#> Error: Internal error: `template` must have a `names` attribute.

Both versions are able to reliably manipulate empty dataframes that were not constructed from matrices (e.g. data.frame() |> dplyr::slice(1) works just fine).

[DavisVaughan]

I think this may actually be a base R bug. I believe that all data.frames should have a names attribute. If there are 0 columns then it should be set to character(). The fact that that isn't the case here is odd.

attributes(as.data.frame(matrix(nrow = 0, ncol = 0)))
#> $class
#> [1] "data.frame"
#> 
#> $row.names
#> integer(0)

attributes(data.frame())
#> $names
#> character(0)
#> 
#> $row.names
#> integer(0)
#> 
#> $class
#> [1] "data.frame"

Not having a names attribute can seriously break other parts of base R, making my guess that it is a base R bug feel more validated:

# Good OOB error
df <- data.frame()
df[1]
#> Error in `[.data.frame`(df, 1): undefined columns selected

# WTF is this
df <- as.data.frame(matrix(nrow = 0, ncol = 0))
df[1]
#> NULL
#> <0 rows> (or 0-length row.names)

In general dplyr works fine with the 2nd case, i.e. a well formed data frame

---

I think we should consider switching from names2() to names() in DataMask to try and catch this earlier on:

dplyr/R/data-mask.R

Line 14 in d698022

names_bindings <- chr_unserialise_unicode(names2(data))

i.e. something like

names <- names(data)

if (is.null(names)) {
  abort("Can't transform a data frame with `NULL` names.")
}

which would go nicely with our other names related checks there.

It did use names() in the past, but I switched to names2() here to supposedly fix this exact case. Supposedly not supporting NULL column names broke 2 packages and that was what I was out to fix, but that seems like a false alarm because current CRAN dplyr obviously already doesn't support NULL column names based on this issue. So the change above would just be giving a better error message for this invalid data frame.
#4896

[DavisVaughan]

This has been fixed upstream in base R wch/r-source@ae3f49f

For TDD, here is what I think we need to do to finish up the dplyr side. The changes take place here:

dplyr/R/data-mask.R

Line 14 in d698022

names_bindings <- chr_unserialise_unicode(names2(data))

We need to switch from names2() to names() so we can check for any issues in the names and throw an error rather than having rlang "repair" them for us. We need to check for 2 things:

• NULL names resulting from names()
• NA names resulting from names()

Both of these are typically "repaired" by rlang

names <- names(data)

if (is.null(names)) {
  abort("Can't transform a data frame with `NULL` names.")
}
if (vec_any_missing(names)) {
  abort("Can't transform a data frame with missing names.")
}

names <- chr_unserialise_unicode(names)