Support `#[builder(derive(Into))]` to generate `From<Builder<impl IsComplete>> for T`

[luveti]

The following shows a macro I use heavily in my code to mostly remove the need to call the finish fn.

macro_rules! builder_to_built_impl {
    ($name:ident) => {
        paste::paste! {
            impl<S: [<$name:snake _builder>]::State + [<$name:snake _builder>]::IsComplete> From<[<$name Builder>]<S>> for $name {
                fn from(value: [<$name Builder>]<S>) -> Self {
                    value.call()
                }
            }
        }
    };
}

struct Foo {
    bar: Option<u32>,
    bazz: bool,
}

#[bon::builder]
fn foo(bar: Option<u32>, bazz: bool) -> Foo {
    Foo { bar, bazz }
}

builder_to_built_impl!(Foo);

fn test(foo: impl Into<Foo>) {}

fn main() {
    test(foo().bazz(false).call());
    test(foo().bazz(true)); // call not required

    // one can now just call `into` instead of `call`
    let test1: Foo = foo().bazz(true).into();

    // `into` is better than calling `call`, as we can support more than just builders
    macro_rules! foos {
        ($($foo:expr),* $(,)?) => {
            vec![$($foo.into(),)*]
        };
    }
    let foos: Vec<Foo> = foos![foo().bazz(true), foo().bazz(false)];
}

I believe this could be better handled by bon directly, as it knows the name of the top-level finish_fn (call in this case). This of course can't be used when a member-level finish_fn is used, since Into can't take arguments.

The proposed syntax change would be:

#[bon::builder(into)]
fn foo(bar: Option<u32>, bazz: bool) -> Foo {
    Foo { bar, bazz }
}

Which would generate:

impl<S: foo_builder::State + foo_builder::IsComplete> From<FooBuilder<S>> for Foo {
    fn from(value: FooBuilder<S>) -> Self {
        value.call()
    }
}

[luveti]

#127 appears to be related.

I still think having the ability to generate a From implementation could be useful for many use cases. As it removes the dependence on bon / makes the code more generic.

More generic, a bunch of types can impl Into<Foo>:

fn test(foo: impl Into<Foo>) {
    let foo = foo.into();
}

Less generic, only accepts a foo builder. Plus the signature is more verbose/noisy:

fn test<S: foo_builder::IsComplete>(foo: FooBuilder<S>) {
    let foo = foo.call();
}

[Veetaha]

Hi! Deriving this From impl is reasonable, although the proposed attribute syntax here should be improved.

#[builder(into)] already is used at the member level to denote setters that accept parameters with impl Into. There is also #[builder(on(_, into))] that enables this behavior for all members.

I'd like to avoid adding another meaning to #[builder(into)] on the top level. As an alternative, there may be #[builder(derive(Into))] that extends the existing #[builder(derive(...))] syntax that denotes functionality derived for the builder type itself.

The unfortunate confusing thing about #[builder(derive(Into))] is that we don't derive Into, we derive From<Builder> for T instead. But I don't really have a better name for such a derive. For example, derive_more provides a derive(Into) and just points out in the docs that it actually generates a From impl instead:

One thing to note is that this derive doesn’t actually generate an implementation for the Into trait. Instead, it derives From for the values contained in the struct and thus has an indirect implementation of Into as recommended by the docs.

Given that derive_more settled with that approach it feels less bad for #[builder(derive(Into))] to actually derive From.

Also, @luveti we can't generate the From impl for async or unsafe functions, and also I think the macro should prohibit generating this impl for functions that return a Result<_>. Using let foo: Result<_> = builder.into(); seems like a bad call smell and I'd like to prohibit that unless a compelling use case arises.

Another limitation here is that functions generic over the return type (fn foo<T>() -> T) won't work as well due to the orphan rules.

So this feature will be limited only to synchronous infallible functions and structs.

[Veetaha]

  // `into` is better than calling `call`, as we can support more than just builders
  macro_rules! foos {
      ($($foo:expr),* $(,)?) => {
          vec![$($foo.into(),)*]
      };
  }

As a sidenote, if you find yourself defining a macro like this, consider using bon::vec![] instead, because it already does exactly that

[luveti]

Given that derive_more settled with that approach it feels less bad for #[builder(derive(Into))] to actually derive From.

That syntax would be perfect!

Also, @luveti we can't generate the From impl for async or unsafe functions, and also I think the macro should prohibit generating this impl for functions that return a Result<_>. Using let foo: Result<_> = builder.into(); seems like a bad call smell and I'd like to prohibit that unless a compelling use case arises.

That seems reasonable. I wouldn't see myself wanting to use .into() in that case anyways, as I'd typicially propagate the error up using ?.

As a sidenote, if you find yourself defining a macro like this, consider using bon::vec![] instead, because it already does exactly that

Nice! The actual name of my macro is els! which is much shorter than bon::vec!, I may use bon::vec! internally though!

[Veetaha]

This feature was implemented in #248 and it'll be merged into master. I'll push a new minor release with it soon. In the meantime I'll push some more PRs to master before I do that release. It should happen today