Feature Request with Proposed Solution: Update utils:::format.object_size() and utils:::print.object_size() to Respect Optional Formatting Arguments
When running the following commands:
x <- numeric(1e8)
format(object.size(x), units = "kB", standard = "SI")
#>  "8e+05 kB"
The object size is returned in scientific notation.
It is natural to assume we could use the argument 'scientific = FASLE'
to solve this.
format(object.size(x), units = "kB", standard = "SI", scientific = FALSE)
#>  "8e+05 kB"
But, the output is unchanged.
We can change the global scipen option to fix this, but this is not
ideal, nor does it address other potential optional arguments a user
may want to pass to format()/print().
ADD lines at the end of the function:
value <- c(round(x/base^power, digits))
dots[["width"]] <- NULL
dots[["digits"]] <- max(ceiling(log10(value)), 0) + digits
dots[["x"]] <- value
format(paste(do.call(format, dots), unit), ...)
By removing any potential 'width' argument and updating the 'digits'
argument to reflect significant digits rather than decimal places in
'dots', the initial value is formatted with any additional arguments
included in the originating generic `format()` call, notably:
digits, nsmall, scientific, big.mark, big.interval, small.mark,
small.interval, decimal.mark, zero.print, and drop0trailing
The outer call to format() will format the character result of paste()
with arguments 'width' and 'justify'.
y <- format.object_size(x, units = units, standard = standard, digits = digits)
y <- format.object_size(x, units, standard, digits, ...)
This simply passes additional arguments to the above edited format.object_size()
These changes have the effect of allowing all possible optional
arguments to format() to be meaningfully used in format.object_size().
Results of the updated function will be identical to the current
results in all cases where no additional arguments have been passed to
the function. So, code which does not rely on these arguments being
ignored will be unaffected.
However, existing code which passes additional formatting arguments
for "object_size" class objects which are currently being ignored may
result in different output. This could potentially cause errors if the
end user is doing anything programmatic with the results, though this
is only likely to cause problems if the code uses but ignores the
'big.mark', 'small.mark', 'decimal.mark', or 'zero.print' arguments
when formatting or printing "object_size" class objects. That said, it
can probably be expected most programmatic work will be done directly
on the "object_size" objects rather than the results of the format()
or print() methods for them. So, I would expect nearly zero issues
with existing code.