all.equal() problems

[krlmlr]

• No tolerance in comparison (No tolerance in dplyr's all.equal.tbl_df() #2264)
• Attributes are not compared (Forward all_equal() to dplyr tibble#198 (comment))
• List columns cannot be compared (Use serialization for columns of type "list" #2355)
• Behavior different depending on the load status of dplyr

Would it be too much of a change to get rid of this override altogether? I propose to emit a warning that all_equal() should be used on tibbles in v0.6, and then remove the specialization in v0.7.

CC @hadley @jennybc.

[hadley]

I think that's ok, although I feel like there's probably quite a few places where I rely on test_equal() working. It's probably better to be explicit though.

An alternative fix would be to write our own all.equal package and systematically work through all of the issues. I'm not sure that's worth the investment now, although it's probably worth it in the long run.

[krlmlr]

@hadley: Are we including this in dplyr 0.6.0?

[hadley]

No, it'll have to wait until the next version.

[PaulHiemstra]

Is it clear when this fix will be included in dplyr?

[mikmart]

Are there any thoughts on when/if attribute checking might be implemented? I'm creating a tbl_df subclass that just adds an attribute, and was surprised when some tests that I expected to fail, didn't.

For now I'm using a (rather janky) workaround with a custom all.equal() method. But this still doesn't allow for simple testing that a lossless roundtrip is possible from tbl_df to the subclass and back.