Feature: support explicit parameter bounds with implicit defaults

[ntc2]

I have a struct, Node<T, D>, where D is phantom, and due to some changes to a type Node embeds, I now need Sync + Send + Any bounds on T to get the various *Eq and *Ord traits on Node<T,D>. This resulted in me needing to make the following change:

-#[derive_where(PartialEq, Eq, PartialOrd, Ord; T)]
+#[derive_where(PartialEq; T: PartialEq + Sync + Send + Any)]
+#[derive_where(Eq; T: Eq + Sync + Send + Any)]
+#[derive_where(PartialOrd; T: PartialOrd + Sync + Send + Any)]
+#[derive_where(Ord; T: Ord + Sync + Send + Any)]
struct Node<T, D> { ... } 

Explanation: whereas before I had a single derive_where call #[derive_where(PartialEq, Eq, PartialOrd, Ord; T)], now I need a separate derive_where call for each of these traits. The reason is that once I add explicit trait bounds T: Sync + Send + Any, I also need to specify the default recursive trait bound as well, which of course is different for each trait I'm deriving.

What I'm proposing is some way to say "I'd like the default bounds for T that I'd get if I didn't give any explicit bounds, plus some explicit bounds". Suppose that underscore (_) stood for the recursive bounds, i.e. the syntax were T: _ + <extra bounds>, leading to #[derive_where(<traits to derive>; T: _ + <extra bounds>)], then the above diff would become

-#[derive_where(PartialEq, Eq, PartialOrd, Ord; T)]
+#[derive_where(PartialEq, Eq, PartialOrd, Ord; T: _ + Sync + Send + Any)]
struct Node<T, D> { ... } 

instead :)

I assume this is a common problem whenever explicit bounds for the generic parameter are specified, but I'm not sure, as this is the first time I've ever needed explicit bounds (usually I'm just using derive_where to ignore phantom parameters).

[ModProg]

Sounds reasonable, @daxpedda do you think _ would conflict with any future ideas of expanding here? Making it be the “implied” bound would be in line with what the '_ lifetime means (and to some extent _ in Generics in general).

[daxpedda]

Agreed, I think this is a nice solution to the problem!