I totally disagree that Default implies an empty value. Such interpretation makes it uncomfortably close to golang’s zero value concept, which in Rust should be done with Option, not Default.
No, it only means that the proposed is_default()might not be useful for such types. However, if the invoked partial-equality is defined only over fields that are deterministic, then is_default() can still be meaningful.
While not PartialEq, here’s an example from stdlib for a type that has nondeterministic default: hashmaps RandomState::default() is an alias RandomState::new() and clearly has non-deterministic behaviour due to seeding happening in the background. I’d also argue this is okay, as the external behaviour stays consistent.
After seeing the official documentation stance on this:
the is_default auto-implemented seems like a very bad idea indeed. It could be used as an additional trait, but it seems far-fetched and unpractical compared to using Options.
If this would be used to omit the value while serialising, it might be dangerous as the deserialising code might have different implementation (e.g different release) that puts a different value in the structure than the originally used.