Proposal: Add is_default() automatically to types that implement Default and PartialEq


That implies that default is deterministic and doesn’t have NaN-like behaviors.

For example, the proposed implementation would not give correct result in such situation:

struct GameConfig {
   seed: usize,

impl Default for GameConfig {
   fn default() -> Self {
     Self {
       seed: random(),


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.


True. The is_default() fn proposed by boats seems useless when the default is non-deterministic.


If Default doesn’t imply deterministic behaviour, then this whole idea is flawed.


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.

I edited my previous post accordingly.


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.