We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
I was curious about a better approach to this awkward separate builder example:
// fn new(pair: Pair<String, String>) -> Self builder().pair( Pair::builder().x("hello").y("world").build() ).build();
The DX could be improved perhaps by supporting closures to abstract another builders entry (T::builder()) + exit (.build()) calls?:
T::builder()
.build()
// Separate builder for `Pair`: // fn new_pair(x: String, y: String) -> Pair<String, String> // type signature for `pair` probably needs to change for builders that leverage it?: // fn new(pair: Pair<String, String>, another_param: Option<bool>) -> Self builder().pair(|p| { p.x("hello").y("world") })
Nesting builders with sub-builders would seem a bit nicer with that approach if it's viable?
This is a bit related to issues:
TryInto<T>
Into<T>
The text was updated successfully, but these errors were encountered:
No branches or pull requests
I was curious about a better approach to this awkward separate builder example:
The DX could be improved perhaps by supporting closures to abstract another builders entry (
T::builder()
) + exit (.build()
) calls?:Nesting builders with sub-builders would seem a bit nicer with that approach if it's viable?
This is a bit related to issues:
TryInto<T>
support +Into<T>
with scalars #186The text was updated successfully, but these errors were encountered: