Overwritable fields with generic types?

[fiadliel]

I've opened an issue on this before (though my idea wasn't a good one): that if the user hasn't set a value for a generic type, the default of the concrete type at build time could be used to fill in the value (avoiding an Option that makes no sense).

e.g. for a scenario like this:

trait Auth {
  fn get_auth(&self) -> Option<String>;
}

struct NoAuth;

impl Auth for NoAuth {
  fn get_auth(&self) -> Option<String> {
    None
  }
}

#[derive(Builder)]
struct Blah<A: Auth> {
  auth: A
}

Flipping the idea on its head: I have an idea that the initial (custom) builder could set a default value, and we then use the experimental_overwritable to replace it later. The fundamental ergonomics (a default concrete value for the generic) are what I want.

It seems possible (but is it wise)? that we add the ability to "unset" a value (Unset<X> is a value where X has been unset). Then when both experimental_generics and experimental_overwritable are set, calling with_x() would wrap all fields with generic type parameter X with Unset. This does break backwards compatibility slightly in the case of this combination, as well as requiring the extra wrapping layer.

Afterwards, the builder could return

fn builder() -> ... {
  Blah::builder().auth(NoAuth)
}

and then you can use that:

let client = builder()
      .conv_a::<BearerAuth>()
      .auth(BearerAuth::new(token))
      .build();

Thoughts on the idea?

[Veetaha]

Hi! My main concern with the direction of the solution design for this problem is the level of its complexity. I would really like to avoid complicating bon's API as it's already quite complex. If you have only one optional generic parameter, you could use #[builder(start_fn)] to provide the value for that field, and make a wrapper method for builder() and auth(). This approach, however, allows you to call auth() only at the start of the call chain:

use bon::Builder;

trait Auth {
    fn get_auth(&self) -> Option<String>;
}

struct NoAuth;

impl Auth for NoAuth {
    fn get_auth(&self) -> Option<String> {
        None
    }
}

struct StaticCreds(String);

impl Auth for StaticCreds {
    fn get_auth(&self) -> Option<String> {
        Some(self.0.clone())
    }
}

#[derive(Builder)]
#[builder(start_fn(name = builder_internal, vis = ""))]
struct Blah<A: Auth> {
    #[builder(start_fn)]
    auth: A,
}

impl BlahBuilder<NoAuth> {
    fn auth<A: Auth>(self, value: A) -> BlahBuilder<A> {
        Blah::builder_internal(value)
    }
}

impl Blah<NoAuth> {
    fn builder() -> BlahBuilder<NoAuth> {
        Blah::builder_internal(NoAuth)
    }
}

fn main() {
    let default = Blah::builder().build();
    let overwritten = Blah::builder()
        .auth(StaticCreds("secret".to_owned()))
        .build();
}

Another way to avoid this problem would be to type-erase the generic and use smth like Box/Arc<dyn Auth>. Would this suffice for your use case?

[fiadliel]

Thanks for replying!

I'm trying to avoid a dyn trait as a requirement so that I can hold onto per-impl error types (eg some may be infallible and some may fail for various reasons).

And there can be a lot of fields that I apply this kind of behavior to, so I'd prefer to keep them as separate unordered parameters.

In the end, I would say bon makes my API possible, I'm very happy with it. Opening this discussion was just about API optimisation.