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

[kornel]

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:

#[derive(PartialEq)]
struct GameConfig {
   seed: usize,
}

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

[kornel]

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.

[Tom-Phinney]

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

[aledomu]

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

[Tom-Phinney]

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.

[skade]

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.

https://doc.rust-lang.org/src/std/collections/hash/map.rs.html#3168-3189

[dhm]

After seeing the official documentation stance on this:

Sometimes, you want to fall back to some kind of default value, and don’t particularly care what it is.

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.

[Rumata]

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.