`tar_map()` does not interpret <integer64> values correctly

[ropensci]

`tar_map()` does not interpret values correctly

from tarchetypes.

[wlandau]

This edge case happens because tar_map() uses targets::tar_deparse_safe() to sanitize what you supply to values in tar_map(). This is a special wrapper around deparse() which effectively sets the control argument to c("keepNA", "keepInteger"). This causes a different set of behaviors than the default deparse() which makes tracking R code for changes more robust in response to user code and less likely to break across different versions of R. That changes how the 64-bit integer class is deparsed.

deparse(bit64::as.integer64(1))
#> [1] "structure(4.94065645841247e-324, class = \"integer64\")"
deparse(bit64::as.integer64(1), control = c("keepNA", "keepInteger"))
#> [1] "4.94065645841247e-324"

Nothing in metaprogramming works for every edge case, which is why the tar_map() help file cautions against passing complicated objects into values.

tarchetypes/R/tar_map.R

Lines 32 to 38 in 507d06b

	#' in place of those symbols. Elements of the `values` list
	#' should be small objects that can easily deparse to names,
	#' such as characters, integers, and symbols.
	#' For more complicated elements of `values`, such as
	#' lists with multiple numeric vectors,
	#' `tar_map()` attempts to parse the elements into expressions,
	#' but this process is not perfect, and the default

tar_meta() tries to create runnable code, so it is best to supply simple objects that can be easily inserted into R expressions without issue.

[psychelzh]

Or is this by design? If so, is there any workaround other than converting it to character manually beforehand?

[psychelzh]

Thanks for explaining.