Vitalii Kryvenko

One more trick. If you want to avoid calling the finishing method, just make the finishing method accept one of the required fields (which, additionally forces the caller to pass...

As for me, the closure syntax is harder to read and compose because now your code is nested inside of anther function. You can no longer easily use the [partial...

In the example shown here the existing API already looks nice. Every method returns a `Tensor` on every step of an operation. Every operation takes only a single parameter. So...

If you'd mix a builder in the middle of these combinators layering (especially, if you remove the explicit `finish_fn` call), then it indeed becomes hard to distinguish where one combinator...

Btw, in the example initial here (I modified it a bit): ```rust impl Tensor { #[builder] fn op1(&self, x: &str, level: Option, op2: Option

@cksac how about this? What if `bon` generates a `From for T` for you, so you can then implement such API with the closure manually if you want. Right now...

Yeah, it indeed requires more code to write, but I doubt there is a popular demand for such builder syntax, although I'm ready to be proven wrong. The gist is...

I don't think there is anything `3.0` to this feature, because it doesn't require a breaking change, I created a separate issue https://github.com/elastio/bon/issues/127 for this. I'm fine with having a...

Closing this in favour of https://github.com/elastio/bon/issues/156

Hi, thank you for creating the issue! Overriding the `maybe_` prefix is indeed something that I've been thinking of having in `bon`. I suppose as a workaround you use `#[builder(setters(option_fn(name...