Hadley Wickham

Do we also need to think about types? i.e. do we want an `equal()` where `equal(1, 1L)` is false? (Maybe with a warning to make it clear that function is...

Also need to think about string encoding - base R takes a very strong opinion that strings are equal if they're equal when re-encoded to UTF-8.

Maybe we should have `vec_equal()` and `vec_identity()` for vectorised and scalar comparison, then options for comparing NAs and FP tolerance?

Hmmm, maybe FP tolerance can stay as part of a specialised function? It's a bit hard to know because so many ideas are tangled up in `all.equal()`: scalar equality, explanation...

Yeah, agreed, it just kind of falls out here because of lists (since they can contain any object you have to handle everything here) It does seem like it would...

I don't think they need to/should be generic because vctrs calls `vec_equality_proxy()` which can return an atomic vector, list, or data frame that is used for comparisons internally (we need...

I don't think the principle of equal values/hashes after serialisation round-trip applies here. It's definitely a useful principle, but I think it's a bit too strict for vctrs needs (which...

One more idea for naming: I could have `obj_equal()`, `vec_equal()`, `obj_identical()`, and `vec_identical()`? A similar distinction is `lobstr::obj_addr()` vs `lobstr::obj_addrs()`, but I don't think plurals would work here.

I think it's most important that you give some thought to the type signature of the generic — i.e. what does it return? Does it return a data frame? A...

I do think this is mostly google's responsibility — for dangerous access levels like this it really should offer some time scoped option (i.e. allow access for the next 4...