r-lib / vctrs

Generic programming with typed R vectors
https://vctrs.r-lib.org
Other
287 stars 66 forks source link

Is the `c()` fallback `name_spec` check too restrictive? #1106

Open DavisVaughan opened 4 years ago

DavisVaughan commented 4 years ago

In slider I was planning on calling vec_unchop(out, .name_spec = zap()) from slide_vec(.x, .f), where out is a list of size 1 results from repeatedly calling .f over the slices of .x.

I don't know the type of the contents of out, but I do know that I don't care about the vec-names of each element of out, so I want to zap them (the names of .x are used instead).

But since out could hold any type, I can't set .name_spec = zap() with the current strictness around the .name_spec because:

library(vctrs)

foobar <- function(x = list()) {
  structure(x, class = "foobar")
}

c.foobar = function(...) {
  xs <- list(...)
  xs <- lapply(xs, unclass)
  out <- vec_unchop(xs)
  foobar(out)
}

vec_c(foobar(1), foobar(2), .name_spec = rlang::zap())
#> Error: Can't use a name specification with non-vctrs types.
#> vctrs methods must be implemented for class `foobar`.
#> See <https://vctrs.r-lib.org/articles/s3-vector.html>.

Maybe we can special case zap() here https://github.com/r-lib/vctrs/blob/3dc326ac95b46eed9c75cade342aa96f3f415230/src/c.c#L212

And use vec_set_names(out, R_NilValue) on this if name_spec = zap() https://github.com/r-lib/vctrs/blob/3dc326ac95b46eed9c75cade342aa96f3f415230/src/c.c#L205

lionel- commented 4 years ago

I think that makes sense.