Closed nicholastmosher closed 3 years ago
Moving defaults to be eagerly created would make the common-case performance worse: We'd run default
functions whose return values we ended up not needing because the caller invoked the appropriate setter method.
If you're going down the path of a custom builder, can you skip using #[builder(default)]
at all, and instead put those defaults directly into your build
function? That way they're still declared once. Alternatively, can you provide a custom implementation of CustomBuilder::default
that has the values you want?
Sure, I think that those are reasonable workarounds. I think it might be worth adding a note to the docs that the #[builder(default)]
attribute doesn't work with a custom builder function, that was the big part that tripped me up. If I have a free moment I'll see if I can make a quick PR for that.
That'd be a great docs update, thanks.
I have a scenario where I would like to use the
#[builder(default = "..")]
attribute, but I would also like to use#[builder(build_fn(skip))]
. I have code like the following that I would expect to work:What I get instead is a panic with "Missing default prefix".
It seems that the builder macro must place the code for handling default values in the generated
build
function, and since I'm not using it, I'm not seeing that behavior occur. I can get around this by usingunwrap_or
in the custom builder, but it was a bit confusing that the default values I'd defined weren't anywhere to be seen.I wonder if it'd be possible to add the default-value generation into the implementation of
Default
for the builder struct instead. That way, usingConfigBuilder::default()
would pre-populate those fields withSome(<value provided in attribute>)
, and a custom builder method could simply unwrap them without needing to duplicate the default-value declarations.