Vitalii Kryvenko

I think the syntax here should be the following. The `expose_positional_fn` attribute should be removed (I never liked it to be honest 😳). Instead, the following should be possible: -...

Hi, sorry, it takes a lot of time to get this resolved just because I'm thinking too much about it and questioning the design again and again. Howerver, this issue...

Sure, I'll ping you once I have a `3.0.0-rc` version

In the meantime, @drmason13 , maybe you could share what specific use case you have for exposing the positional function? Is this required for only backwards compatibility, or do you...

I see, thanks for clarifying

I've published a 3.0.0-rc version of bon. The new way to expose original function is described here: https://bon-rs.com/reference/builder/top-level/start_fn#exposing-original-function

I'll close this issue as fixed. Feel free to reopen or create a new issue if you have some more ideas for the api

Thank you for bringing this up! This is definitely a controversial topic because of the confrontation between high-level non-performance-sensitive code and low-level performance-sensitive code. This confrontation influences the default behaviour...

> even if it is more ergonomic for callers > might even belong in a separate crate, though. This is the main thing. The `bon` crate is this exact crate...

Unfortunatelly, cargo features don't work that way. They must be additive because they undergo [feature unification](https://doc.rust-lang.org/cargo/reference/features.html#feature-unification) between all the crates in the dependency tree. There can't be one crate that...