c() fails where c.integer64() passes for nanotime

[MichaelChirico]

See eddelbuettel/nanotime#137 (comment).

This necessitates c.integer64 being exported. Is there any workaround?

[hcirellu]

If the as.integer64.integer64() is modified as I proposed in (#188) to an R like behavior, the c.nanotime() and c.nanoduration() could be modified to:

c.nanotime <- function(...) {
  dots <- list(...)
  dots[[1L]] <- as.integer64(dots[[1L]])
  nanotime(do.call("c", dots))
}

In this combination it worked out well in my test cases, without exporting c.integer64().

Another approach is a few comments later, cf. c.myInt64.

[MichaelChirico]

Now that #188 is merged, let's revisit with a proposed patch to {nanotime} once #188 is included in a CRAN release.

[MichaelChirico]

I suspect we'll want to keep exporting c.integer64().

Fundamentally, c() cannot work in R for now:

c(1L, as.integer64(2L))
# [1]  1.000000e+00 9.881313e-324
c.integer64(1L, as.integer64(2L))
# integer64
# [1] 1 2

As long as we can't force S3 (or S4, for that matter) dispatch to use our method, users will want this as a workaround.

[hcirellu]

Well, if I'm not sure about the incoming data types and assume that there might be an integer64 argument, I would call c(integer64(), <the_other_arguments>) and not use c.integer64(<the_other_arguments>).

[hcirellu]

When I create an S4 class on top of integer64, the behaviour is what I expect.

setClass("myInt64", contains = "integer64")
myInt64 = function(x) {
    if (missing(x)) 
      x = NULL
    setNames(new("myInt64", as.integer64(x)), names(x))
}
as.myInt64 = function(x) {myInt64({attributes(x) = NULL; x})}
setAs("ANY", "myInt64", function(from) as.myInt64(from))
c.myInt64 = function(..., recursive=FALSE) myInt64(c(integer64(), ..., recursive=recursive))

myInt64 keeps the names.

myInt64(1:2)
# Object of class "myInt64"
# integer64
# [1] 1 2
myInt64(c(a=1:2))
# Object of class "myInt64"
# integer64
# a1 a2 
#  1  2 

as drops the names.

as.myInt64(1:2)
# Object of class "myInt64"
# integer64
# [1] 1 2
as.myInt64(c(a=1:2))
# Object of class "myInt64"
# integer64
# [1] 1 2
as(1:5, "myInt64")
# Object of class "myInt64"
# integer64
# [1] 1 2 3 4 5
as(c(a=1:2), "myInt64")
# Object of class "myInt64"
# integer64
# [1] 1 2

c keeps the names.

c(myInt64(c(a=1:2)), myInt64(c(b=2L)))
# Object of class "myInt64"
# integer64
# a1 a2  b 
#  1  2  2 
c(myInt64(c(a=1:2)), c(b=2))
# Object of class "myInt64"
# integer64
# a1 a2  b 
#  1  2  2 
c(myInt64(), c(a=as.integer64(1:2)), c(b=2))
# Object of class "myInt64"
# integer64
# a1 a2  b 
#  1  2  2 

[MichaelChirico]

My original concern was packages running c() out-of-order and destroying the object, but actually c.integer64() doesn't help there either.

So maybe, it's like this:

Anyone who was going to write c.integer64(...) knows they're trying to preserve integer64, and can control the input ordering. And yes you gave the nice solution of just prepending integer64() in c() to get equivalent behavior -- the alternative of "just coerce the first input" is not as nice because that requires you to think through what the output type will be.

A PR adding your workaround to documentation would be very helpful, I reckon.

[MichaelChirico]

#330 includes mentioning c(integer64(), ...) in the documentation. I haven't seen any counterexamples yet -- it seems equivalent.