different results for bit64::as.integer64(10L, 20L) and bit64::as.integer64(c(10L, 20L))

[edward-burn]

I was looking into a test failure on the development dbplyr (tidyverse/dbplyr#1564) and it seems to be caused by the below. I'm not sure if it is a bug, but I thought I'd report here in case (as it seems to be a test that used to pass but no longer)

https://github.com/tidyverse/dbplyr/blob/572693098d0098018b6bb2d1e88b650d2e1e1580/tests/testthat/test-backend-postgres.R#L338

bit64::as.integer64(10L)
#> integer64
#> [1] 10
bit64::as.integer64(20L)
#> integer64
#> [1] 20
# as is in test
bit64::as.integer64(10L, 20L)
#> integer64
#> [1] 10
# workaround
bit64::as.integer64(c(10L, 20L))
#> integer64
#> [1] 10 20

^{Created on 2024-12-29 with reprex v2.1.0}

[MichaelChirico]

bit64::as.integer64(10L, 20L) looks wrong, I would not expect this to work, the "workaround" is the canonical approach.

The behavior to just ignore all but the first argument is the same as the behavior of as.numeric(), as.integer(), as.character()....

I also checked all released {bit64} versions since 0.9-2 (2012) and current main and they all give the same thing for as.integer64(10L,20L), so I don't see any change in behavior either.