Hash of vec_slice() return value disagrees with base R equivalent (on R-devel)

[wlandau]

On R-devel (2026-02-03), vec_slice() returns objects which hash differently from their base R equivalents. This may seem like an edge case, but targets depends on the ability to reliably hash slices, and its tests on R-devel are currently failing.

Reprex:

library(vectors)

x <- c(1L, 3L, 5L)
a <- 1L
b <- x[1L]
c <- vctrs::vec_slice(x, 1L)

identical(a, b) # TRUE
identical(a, c) # TRUE
identical(b, c) # TRUE

digest::digest(a) # "4b5630ee914e848e8d07221556b0a2fb"
digest::digest(b) # "4b5630ee914e848e8d07221556b0a2fb"
digest::digest(c) # "f7e26430e6335947766e82d7459e9d77" -- different!

I get the same result both with version 0.7.1 of vctrs (current CRAN) and with 94cea16. The hashes only agree if I switch back to R-release (4.5.2).

Session info

> sessioninfo::session_info()
─ Session info ──────────────────────────────────────────────────────────────────────────────────────
 setting  value
 version  R Under development (unstable) (2026-02-03 r89375)
 os       Red Hat Enterprise Linux 9.7 (Plow)
 system   x86_64, linux-gnu
 ui       X11
 language (EN)
 collate  en_US.UTF-8
 ctype    en_US.UTF-8
 tz       America/Indiana/Indianapolis
 date     2026-02-06
 pandoc   2.14.0.3 @ /usr/bin/pandoc
 quarto   1.6.42 @ /home/CENSORED/.local/bin/quarto

─ Packages ──────────────────────────────────────────────────────────────────────────────────────────
 package     * version    date (UTC) lib source
 cli           3.6.5      2025-04-23 [1] RSPM (R 4.6.0)
 digest        0.6.39     2025-11-19 [1] RSPM (R 4.6.0)
 rlang         1.1.7      2026-01-09 [1] RSPM (R 4.6.0)
 sessioninfo   1.2.3      2025-02-05 [1] RSPM (R 4.6.0)
 vctrs         0.7.1.9000 2026-02-06 [1] Github (r-lib/vctrs@94cea16)

 [1] /home/c240390/R-devel/library

[wlandau]

digest::digest(rlang::duplicate(c)) returns "4b5630ee914e848e8d07221556b0a2fb", so that may be a temporary patch to get targets working again on R-devel for its next release. But in the long term, I would prefer to avoid creating so many deep copies.

Edit: shallow copies are not enough for data frames, unfortunately. On R-devel (2026-02-03):

digest(mtcars[2, ]) # 890f7863f66cb6dc6843f935a6992e97 (same on R 4.5.2)
digest(duplicate(vec_slice(mtcars, 2), shallow = FALSE)) # 890f7863f66cb6dc6843f935a6992e97
digest(duplicate(vec_slice(mtcars, 2), shallow = TRUE)) # 230a68f0a4c767a7ac48ff4c876c4210

[DavisVaughan]

@lionel- this looks to be from using the new R_allocResizableVector() in R 4.6.0

https://github.com/r-lib/rlang/blob/5a437884b3730ae1973effcd06e3070a21b5b7fd/src/rlang/vec.h#L188

> .Internal(inspect(a))
@142699958 13 INTSXP g1c1 [MARK,REF(3)] (len=1, tl=0) 1
> .Internal(inspect(b))
@1426ab2f0 13 INTSXP g1c1 [MARK,REF(2)] (len=1, tl=0) 1
> .Internal(inspect(c))
@142d30978 13 INTSXP g1c1 [MARK,REF(2),gp=0x20] (len=1, tl=1, gr) 1

Although I'm not really sure what the right expectations really should be here.

I did have a small worry at the time of implementing r-lib/rlang#1856 that maybe there would be some edge cases where switching to always using resizable vectors might not work perfectly, and this seems to be one of those cases.

I think we do really prefer R_allocResizableVector() though.

[lionel-]

Will, would it make sense to hash a type tag + data instead of a whole object, to avoid getting to depend on internal representation details?

[wlandau]

I'm concerned that might get too low-level for targets because of how complicated the sliced object may be in the general case.

[lionel-]

Would you be able to take a dependency for this?
Edit: oh I see you already depend on rlang and vctrs, hmm

[lionel-]

@wlandau I've reimplemented rlang::hash() to only be sensitive to user-visible data, in case you'd like to try it: r-lib/rlang#1895