New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

all.equal() problems #2751

krlmlr opened this Issue May 6, 2017 · 5 comments


None yet
4 participants

krlmlr commented May 6, 2017

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.


This comment has been minimized.


hadley commented May 8, 2017

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 krlmlr added this to To-do in krlmlr May 15, 2017


This comment has been minimized.


krlmlr commented May 15, 2017

@hadley: Are we including this in dplyr 0.6.0?


This comment has been minimized.


hadley commented May 15, 2017

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


This comment has been minimized.

PaulHiemstra commented Oct 26, 2017

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

topepo pushed a commit to tidymodels/recipes that referenced this issue Jan 10, 2018

Max Kuhn

@krlmlr krlmlr removed this from To-do in krlmlr Jun 28, 2018


This comment has been minimized.

mikmart commented Aug 3, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment