Why new_without_default is shown for structs with private fields?

[ozkriff]

No description provided.

[oli-obk]

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().

[ozkriff]

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)

[oli-obk]

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.

[rail-rain]

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.

[oli-obk]

Thanks! you're right, this is indeed fixed