Can you elaborate on the issue you have with this? If you have an fn new() -> Self that you can call as T::new(), there's no disadvantage to also offering a T::default().
It requires me to write five lines of code (for each such class) which most likely will be useless for me, as I don't often see Default used with complex objects with private fields and internal invariants. I think that useful Default implementation for such objects is an exception rather than the rule.
impl Default for Simulator {
fn default() -> Simulator {
Simulator::new()
}
}
(Ahem. As always, sorry for my English)
which most likely will be useless for me
Emphasis (mine): most likely. For public types this can be a serious usability problem. A user of your object might need to manually impl Default with many fields just because that one field doesn't impl Default, when they otherwise could have slapped a #[derive(Default)] onto their struct.
I'd be totally fine only linting for pub types and ignoring all pub(crate) and friends.
Hello, is there any work needed to close this issue? Since the author +1-ing oli-obk's last comment and that feature had already been implemented in #972 IIUC, I believe you can close this issue.
Thanks! you're right, this is indeed fixed
Most helpful comment
Emphasis (mine): most likely. For public types this can be a serious usability problem. A user of your object might need to manually impl
Defaultwith many fields just because that one field doesn't implDefault, when they otherwise could have slapped a#[derive(Default)]onto their struct.I'd be totally fine only linting for
pubtypes and ignoring allpub(crate)and friends.