Private derive(Default) ergonomics [PDDE], vs blanket impls, vs other alternatives

language design
2

This sounds like as if PPDE would be an abbreviation of something and like there were previous discussions on these topics before (“Ppl don't seem to want either of them tho.”)

Edit: Oh, it’s in the title! “ Private derive(Default) ergonomics”

Would you mind resolving the acronym and also, in case you have them at hand, add links to previous discussions?

Also, I personally like the idea of allowing blanket impls for local traits.

For the derive macros, I think it would be nice if there was a way to speficy the bounds manually. E.g.

#[derive(Default)]
#[default_where()] // ensures that `T: Default` isn’t required
struct S1<T> {
    field: Option<T>,
}

#[derive(Default)]
#[default_where(<T as ToOwned>::Owned: Default)]
struct S2<'a, T: ?Sized>
where
    T: ToOwned,
{
    field: Cow<'a, T>,
}

then, specifying no where clause would be the same as the current behavior, T: Default for every type parameter T. In either case, the actual Default implementation has a combined where clause consisting of the struct’s own where clause and bounds, and additionally the explicit or implicit additional constraints.

Maybe this can also lead to a way to make PPDE less confusing, i.e. make them explicit, something like

#[default_where(_)]

or

#[default_where(...)]

or

#[default_where(inferred)]

that only works for non-pub types.

All of this could be tested in an external crate with a new, alternative, Default derive macro.

A need for derive ergnonomics like that or a way to explicitly give the where-clause also applies to pretty much every other trait in the standard library that can be inferred, right?

2 Likes