Defines new notions of prototype and size that are used to provide tools for consistent and well-founded type-coercion and size-recycling, and are in turn connected to ideas of type- and size-stability useful for analyzing function interfaces.
There are three main goals to the vctrs package, each described in a vignette:
vec_type() as alternatives to
vignette("type-size"). These definitions
are paired with a framework for type-coercion and size-recycling.
To define type- and size-stability as desirable function properties,
use them to analyse existing base function, and to propose better
vignette("stability"). This work has been
particularly motivated by thinking about the ideal properties of
To provide a new
vctr base class that makes it easy to create new
vignette("s3-vector"). vctrs provides methods for many
base generics in terms of a few new vctrs generics, making
implementation considerably simpler and more robust.
vctrs is a developer focused package. Understanding and extending vctrs requires some effort from developers, but should be invisible to most users. It’s our hope that having an underlying theory will mean that users can build up an accurate mental model without explicitly learning the theory. vctrs will typically be used by other packages, making it easy for them to provide new classes of S3 vectors that are supported throughout the tidyverse (and beyond). For that reason, vctrs has few dependencies.
vctrs is not currently on CRAN. Install the development version from GitHub with:
library(vctrs)# Prototypesstr(vec_type_common(FALSE, 1L, 2.5))#> num(0)str(vec_cast_common(FALSE, 1L, 2.5))#> List of 3#> $ : num 0#> $ : num 1#> $ : num 2.5# Sizesstr(vec_size_common(1, 1:10))#> int 10str(vec_recycle_common(1, 1:10))#> List of 2#> $ : num [1:10] 1 1 1 1 1 1 1 1 1 1#> $ : int [1:10] 1 2 3 4 5 6 7 8 9 10
The original motivation for vctrs from two separate, but related
problems. The first problem is that
base::c() has rather undesirable
behaviour when you mix different S3 vectors:
# combining factors makes integersc(factor("a"), factor("b"))#>  1 1# combing dates and date-times give incorrect valuesdt <- as.Date("2020-01-1")dttm <- as.POSIXct(dt)c(dt, dttm)#>  "2020-01-01" "4321940-06-07"c(dttm, dt)#>  "2019-12-31 18:00:00 CST" "1969-12-31 23:04:22 CST"
This behaviour arises because
c() has dual purposes: as well as it’s
primary duty of combining vectors, it has a secondary duty of stripping
attributes. For example,
?POSIXct suggests that you should use
if you want to reset the timezone.
The second problem is that
dplyr::bind_rows() is not extensible by
others. Currently, it handles arbitrary S3 classes using heuristics, but
these often fail, and it feels like we really need to think through the
problem in order to build a principled solution. This intersects with
the need to cleanly support more types of data frame columns including
lists of data frames, data frames, and matrices.