forward default typeparam

[tharvik]

the derived builder doesn't offer the same default types as the source struct. that forces the user to explicit all types when theses can't be infered.

in the case I have, I want to derive a builder on a struct with a bunch of callbacks:

pub struct Settings<T, S = fn(T), R = fn(T), C = fn(T)>
where S: FnOnce(T), R: FnMut(T), C: FnMut(T)

on which I only need to specific T when instanciating Settings "by hand". but when using the derived builder, I need to specifiy all the types (which is especially cumbersome as most of theses callbacks are optional).

there was a confusion in the implementation between generics meant for the builder struct (which can contain default types) and the ones for impl (which can't contain theses). this PR fixes that by directly using the generics specified on the struct (with bounds and defaults), and a test to guard against regression for this kinda obscure feature.

I encountered dtolnay/syn#782 while doing that but as it seems that upstream seems to have forgot this issue, a workaround seemed better.

[TedDriggs]

When I last tried this in #282, I was surprised to find that it didn't work the way I'd predicted. Does the test case from that conversation work with this PR?

[tharvik]

When I last tried this in #282, I was surprised to find that it didn't work the way I'd predicted. Does the test case from that conversation work with this PR?

No, it doesn't, but that's a way larger issue on how default type params are handled. It won't ~work as predicted until upstream addresses it: one still needs to specify some generic params. but that reduces the number of needed params from my use case from four to one which is already a step in the right direction.

Note that slightly modified version of your test case would work but is quite weird to use

#[test]
fn generic_builder_with_defaults() {
    let x: GenericWithDefaultBuilder = Default::default();
    let y = x.build().unwrap();

    assert_eq!(y, GenericWithDefault { lorem: None });
}