I don't know if we'll ever get there because the value is modest and the effort is non trivial, but it's interesting and if constructive needs to really "tell the truth" it should know about this.
x <- structure(1, names = "a", foo = 2)
y <- structure(1, foo = 2, names = "a")
identical() doesn't care about attribute order (by default!)
construct() doesn't either
dput() and construct_dput() mostly care, but the fact that names are inlined means names is always the first attribute in generated objects.
We have several ways to address this :
The simplest one is to manage to always trigger name repair with construct_dput()
We can also integrate an attribute order check in is_corrupted_, to use the next constructor, but that means passing a new arg to it and researching idiomatic attribute order
We can modify the attribute reparation step and call |> (`attributes<-`)(attributes(x)[c(3,1,2)])
The last one seems the most appealing to me.
I think we have a new arg in construct(), caught by the repair_attributes_ function, this function generates a reordering sequence, NULL if no sorting is required, then .cstr_repair_attributes() builds the code. In some cases like data.frame and variants, we might just add [] to reorder the attributes.
It might that we don't change much code if we turn it on by default, though I suspect the names attributes and the data frame subsetting shuffle will. So better keep optional, probably
I don't know if we'll ever get there because the value is modest and the effort is non trivial, but it's interesting and if constructive needs to really "tell the truth" it should know about this.
identical()doesn't care about attribute order (by default!)construct()doesn't eitherdput()andconstruct_dput()mostly care, but the fact that names are inlined means names is always the first attribute in generated objects.We have several ways to address this :
is_corrupted_, to use the next constructor, but that means passing a new arg to it and researching idiomatic attribute order|> (`attributes<-`)(attributes(x)[c(3,1,2)])The last one seems the most appealing to me.
I think we have a new arg in construct(), caught by the
repair_attributes_function, this function generates a reordering sequence, NULL if no sorting is required, then.cstr_repair_attributes()builds the code. In some cases like data.frame and variants, we might just add[]to reorder the attributes.It might that we don't change much code if we turn it on by default, though I suspect the
namesattributes and the data frame subsetting shuffle will. So better keep optional, probably