#[builder(setter(transform_generics = "<...>"))] to add generics to the transform closure.

[zakstucke]

Love the library!

This PR adds a transform_generics config to allow adding generic parameters and lifetimes to the closure provided by #[builder(setter(transform = "..."))]

The goal is to be able to replicate this setter:

pub fn set_s<M>(s: impl IntoValue<String, M>) -> String {
    s.into_value()
}

And with this PR can be done as:

#[derive(TypedBuilder)]
struct Foo {
    #[builder(
        setter(
            transform_generics = "<__Marker>",
            transform = |value: impl IntoValue<String, __Marker>| value.into_value()
        )
    )]
    s: String,
}

I don't have any preference for this specific syntax, this just seemed to be the simplest non-breaking way to add the functionality, happy to change the implementation if it still adds the same new functionality?

An example of a usecase for this (real usecase in leptos):

struct MBaseCase;

struct MClosure;

trait IntoValue<T, M> {
    fn into_value(self) -> T;
}

impl<T, I> IntoValue<T, MBaseCase> for I
where
    I: Into<T>,
{
    fn into_value(self) -> T {
        self.into()
    }
}

impl<T, F> IntoValue<T, MClosure> for F
where
    F: FnOnce() -> T,
{
    fn into_value(self) -> T {
        self()
    }
}

With this custom transform setter, I can now use either T or || T

[zakstucke]

Hi @idanarye, could you please trigger CI when you get a chance? It needs maintainer approval. Thanks!

[zakstucke]

Example of new syntax:

    #[derive(TypedBuilder)]
    struct Foo {
        #[builder(
            setter(
                fn transform<'a, M>(value: impl IntoValue<'a, String, M>) -> String
                where
                    M: 'a,
                 {
                    value.into_value()
                },
            )
        )]
        s: String,
    }

Existing closure syntax is still supported, so this would still be a minor release

[idanarye]

I'm starting to wonder - maybe instead of ItemFn this should be generalized as an Item? Or would that be too hard to work with?

[zakstucke]

I just tried but it does make it harder to work with, it just requires adding support in a few methods for a lot of variants not currently used. I'd prefer to leave as is unless you feel strongly about it?

[zakstucke]

Hi @idanarye, this is ready for re-review whenever you're ready :)