You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This would make it different from c(a = 1) == c(b = 1). This might reflect a design difference between vctrs and base R.
In base R, == compares [[ slices of atomic vectors, hence the names are excluded from the comparison.
In vctrs, atomic types do not have exposed atoms. Only recursive types allow extraction of data. vec_equal() operates on data proxys and hence is not affected by attributes in general. But vector names are special vector data with ad hoc support.
Probably shouldn't. Names are used as metadata in many code patterns. If they are relevant, they could be converted to a tibble column so they are treated as actual data.
This would make it different from
c(a = 1) == c(b = 1)
. This might reflect a design difference between vctrs and base R.In base R,
==
compares[[
slices of atomic vectors, hence the names are excluded from the comparison.In vctrs, atomic types do not have exposed atoms. Only recursive types allow extraction of data.
vec_equal()
operates on data proxys and hence is not affected by attributes in general. But vector names are special vector data with ad hoc support.See also #141 (comment).
More importantly, what are the practical implications of comparing names in
vec_equal()
?The text was updated successfully, but these errors were encountered: