Copy default generic types from source

[ColonelThirtyTwo]

Example code:

use derive_builder::Builder;


#[derive(Builder)]
pub struct Foo<T = u32> {
    pub v: T
}

The derived FooBuilder has a single generic type <T> like Foo, but it does not copy the default type u32 from Foo - it must be specified manually or inferred. It would be convenient if the builder copied the default type.

[TedDriggs]

This is likely because of this line; we use the syn method for splitting generics for codegen, but that assumes the caller is creating a new impl block rather than redeclaring the struct.

If someone can submit a PR with it and some tests, then I'll be happy to review it - otherwise, I'll take a look when I'm next able.

[TedDriggs]

@ColonelThirtyTwo I tried changing that line, and successfully got the defaults to emit. However, I'd have expected the change to make the following code work, and it doesn't:

#[derive(Debug, PartialEq, Default, Builder, Clone)]
pub struct GenericWithDefault<T = usize> {
    #[builder(default, setter(strip_option))]
    lorem: Option<T>,
}

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

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

The compiler says it cannot figure out the type of x, which suggests to me that the default value for T doesn't flow through the usage of default(). If that is the case, what's the value of this change?

[ColonelThirtyTwo]

I'm not sure what you'd like me to test without seeing the code that you changed.

My particular use case is more along the lines of:

#[derive(Builder)]
#[builder(pattern = "owned")]
pub struct Options<Error = std::io::Error> {
    pub on_error: Box<dyn FnMut(Error)>;
}

Ideally error would default to std::io::Error. Maybe rust's type inference isn't good enough to suss that out, but I can't test it without the change you mae.

[TedDriggs]

It's on the branch generics

[TedDriggs]

@ColonelThirtyTwo did the branch fix your issue?

[TedDriggs]

Since the proposal in this issue doesn't fix the problem described in the issue and there hasn't been any activity in 4 months, I'm going to close this as Not Pompleted.