`vec_ptype()` should not retain attributes on atomics

[DavisVaughan]

Consider the following:

library(vctrs)

x <- structure(1, foo = "bar")
y <- 2

# This should not retain `foo`
vec_ptype(x)
#> numeric(0)
#> attr(,"foo")
#> [1] "bar"

# Note how the attributes are dropped as soon as you introduce
# a `ptype2` combination
vec_ptype2(x, y)
#> numeric(0)

# This currently results in the following inconsistency.
# The "common type" is just `numeric()` so no attribute should be retained.
vec_c(x)
#> [1] 1
#> attr(,"foo")
#> [1] "bar"
vec_c(x, y)
#> [1] 1 2

We preserve attributes in vec_ptype() here in vec_ptype_slice():

vctrs/src/ptype.c

Lines 13 to 44 in b63a233

	r_obj* vec_ptype(r_obj* x, struct vctrs_arg* x_arg, struct r_lazy call) {
	switch (vec_typeof(x)) {
	case VCTRS_TYPE_null: return r_null;
	case VCTRS_TYPE_unspecified: return vctrs_shared_empty_uns;
	case VCTRS_TYPE_logical: return vec_ptype_slice(x, r_globals.empty_lgl);
	case VCTRS_TYPE_integer: return vec_ptype_slice(x, r_globals.empty_int);
	case VCTRS_TYPE_double: return vec_ptype_slice(x, r_globals.empty_dbl);
	case VCTRS_TYPE_complex: return vec_ptype_slice(x, r_globals.empty_cpl);
	case VCTRS_TYPE_character: return vec_ptype_slice(x, r_globals.empty_chr);
	case VCTRS_TYPE_raw: return vec_ptype_slice(x, r_globals.empty_raw);
	case VCTRS_TYPE_list: return vec_ptype_slice(x, r_globals.empty_list);
	case VCTRS_TYPE_dataframe: return df_ptype(x, true);
	case VCTRS_TYPE_s3: return s3_ptype(x, x_arg, call);
	case VCTRS_TYPE_scalar: stop_scalar_type(x, x_arg, call);
	}
	r_stop_unreachable();
	}
	static
	r_obj* col_ptype(r_obj* x) {
	return vec_ptype(x, vec_args.empty, r_lazy_null);
	}
	static inline
	r_obj* vec_ptype_slice(r_obj* x, r_obj* empty) {
	if (r_attrib(x) == r_null) {
	return empty;
	} else {
	// Slicing preserves attributes
	return vec_slice(x, r_null);
	}
	}

I think we need to retain shape (for arrays) but should not retain any other attributes here.

This would affect the following tests

# This would just be `dbl()` rather than `named(dbl())` which I think is right.
# This supports our general view that names aren't part of the ptype.

# This might change in the future if we decide that prototypes don't
# have names
test_that("vec_ptype() preserves type of names and row names", {
  expect_identical(vec_ptype(c(foo = 1)), named(dbl()))
  expect_identical(vec_ptype(mtcars), mtcars[0, ])
  expect_identical(vec_ptype(foobar(mtcars)), foobar(mtcars[0, ]))
})

# I think we should consider that `structure(FALSE, foo = "bar")` and `FALSE` 
# ARE the same type. i.e. extraneous attributes on an object don't affect its
# ptype, so should not affect this computation.
#
# We certainly declare that `vec_ptype2(structure(1, foo = "bar"), 2)` has a common
# type of `numeric()`, so I'm not sure why this is any different

test_that("attributes of unclassed vectors are asserted", {
  x <- structure(FALSE, foo = "bar")
  y <- structure(TRUE, foo = "bar")
  expect_false(vec_is(x, FALSE))
  expect_false(vec_is(FALSE, x))
  expect_true(vec_is(y, x))
  expect_true(vec_is(x, y))
})

This is how this came up for me

x <- c(1, 2, 3)
from <- c(2, 3)

# `foo` is extraneous, this is just a double vector
to <- structure(c(0, -1), foo = "bar")

# TODO: Ideally the attributes wouldn't show up on the output, but
# `list_combine()` doesn't clear them because `vec_ptype(to)` retains
# them
vec_recode_values(x, from = from, to = to)
#> [1] NA  0 -1
#> attr(,"foo")
#> [1] "bar"

# As soon as you introduce ptype2, attributes drop off
vec_recode_values(x, from = from, to = to, default = 0)
#> [1]  0  0 -1

[robchallen]

I've spent a bit of time on what I think is this issue in the context of a date attribute on a numeric.
In my use case where the attribute is an important part of the interpretation then dropping it would be a problem. However the current behaviour is also problematic with regards to dates only.:

BTW I can work around this specific issue by enforcing type checking on the date attribute on my S3 class but I was hoping the example below might be useful, and if you are going to drop the attributes in your check completely I will need to redesign.

testthat::test_that("S3 column with date attribute can be joined", {
  
  # I wasn't sure what to expect here however
  # integer based dates are comparable with double based dates in vec_ptype2
  lhs2 = dplyr::tibble(
    time = as.Date(as.integer(0:9)),
    col1 = "test_lhs"
  )
  
  rhs2 = dplyr::tibble(
    time = as.Date(as.numeric(0:9)),
    col2 = "test_rhs"
  )
  
  # PASSES AS IS:
  testthat::expect_no_error({
    dplyr::left_join(lhs2, rhs2, by = c("time"))
  })
  
  # However comparison of datatypes fails if the dates are held in attributes:
  # This is a time based S3 example:
  lhs = dplyr::tibble(
    id = structure(
      1:10,
      origin = as.Date(as.integer(0)),
      class = c("testS3type", "numeric")
    ),
    col1 = "test_lhs"
  )

  rhs = dplyr::tibble(
    id = structure(
      1:10,
      origin = as.Date(as.numeric(0)),
      class = c("testS3type", "numeric")
    ),
    col2 = "test_rhs"
  )

  # FAILS because vec_ptype2 does not like the date attribute on the time column
  # being numeric and integer. They are not identical (but they are equal)
  # Ideally this would pass (I.e. the join should work, as the date in the attribute is
  # equal in lhs and rhs)
  testthat::expect_no_error({
    dplyr::left_join(lhs, rhs, by = "id")
  })
  
  # On the other hand in this example we have a different attribute value:
  # I.e. lhs origin != rhs origin && they are not identical
  lhs3 = dplyr::tibble(
    id = structure(
      1:10,
      origin = as.Date(as.numeric(1)),
      class = c("testS3type", "numeric")
    ),
    col1 = "test_lhs"
  )
  
  rhs3 = dplyr::tibble(
    id = structure(
      1:10,
      origin = as.Date(as.numeric(0)),
      class = c("testS3type", "numeric")
    ),
    col2 = "test_rhs"
  )
  
  # Currently passes (i.e. the join fails) and I'd like it to continue to pass
  # as the join would be semantically incorrect in the context of this S3 type.
  testthat::expect_error({
    dplyr::left_join(lhs3, rhs3, by = "id")
  })
  
  # N.b.
  # Wierdly these dates are identical
  testthat::expect_true(identical(
    as.Date(0, "1970-01-01"),
    as.Date(0L, "1970-01-01")
  ))
  
  # But these aren't
  testthat::expect_false(identical(
    as.Date(0),
    as.Date(0L)
  ))
  
})

[robchallen]

And I'm not sure if this is more useful:

  lhs = dplyr::tibble(
    id = structure(
      1:10,
      origin = as.Date(as.integer(0)),
      class = c("testS3type", "numeric")
    ),
    col1 = "test_lhs"
  )

  rhs = dplyr::tibble(
    id = structure(
      1:10,
      origin = as.Date(as.numeric(0)),
      class = c("testS3type", "numeric")
    ),
    col2 = "test_rhs"
  )
  
  dplyr::left_join(lhs, rhs, by = "id")
#> Error in `dplyr::left_join()`:
#> ! Can't join `x$id` with `y$id` due to incompatible types.
#> ℹ `x$id` is a <testS3type>.
#> ℹ `y$id` is a <testS3type>.

^{Created on 2025-12-08 with reprex v2.1.1}

[DavisVaughan]

I think you should really be implementing full vctrs methods for your testS3type class rather than relying on our defaults for atomic vectors. i.e. you should probably be implementing vec_ptype2() and vec_cast() methods at a minimum for your class so that you can direct the coercion