Skip to content
New issue

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

Support arbitrary expression for #[builder(default = ...)] #330

Closed
bew opened this issue Sep 5, 2024 · 4 comments · Fixed by #331
Closed

Support arbitrary expression for #[builder(default = ...)] #330

bew opened this issue Sep 5, 2024 · 4 comments · Fixed by #331

Comments

@bew
Copy link

bew commented Sep 5, 2024

Hello!

I initially tried out the typed-builder crate but realized I needed runtime checks.
While migrating to derive_builder I noticed the syntax for default is less ergonomic.

With typed-builder I could do: #[builder(default = "foo".into())]
But with derive_builder I need to wrap the fn in a string: #[builder(default = r#""foo".into()"#)] which is much less ergonomic, and in an editor I can't do actions like 'go-to-definition'.

So here I am, asking to support that ;)

TedDriggs added a commit that referenced this issue Sep 11, 2024
For backwards compatibility, strings are still interpreted as code inside a string.

Fixes #330
@TedDriggs
Copy link
Collaborator

I've put up a PR for this, though I haven't had enough time to fully test it, and I was seeing some weird behavior from rust-analyzer in vscode after I made the change.

TedDriggs added a commit that referenced this issue Oct 2, 2024
For backwards compatibility, strings are still interpreted as code inside a string.

Fixes #330
TedDriggs added a commit that referenced this issue Oct 2, 2024
For backwards compatibility, strings are still interpreted as code inside a string.

Fixes #330
TedDriggs added a commit that referenced this issue Oct 2, 2024
For backwards compatibility, strings are still interpreted as code inside a string.

Fixes #330
TedDriggs added a commit that referenced this issue Oct 2, 2024
For backwards compatibility, strings are still interpreted as code inside a string.

Fixes #330
@bew
Copy link
Author

bew commented Oct 2, 2024

Hello again, thanks a lot for the impl it looks great and simple!

Do you have any plans to make a release some time 'soon'(-ish) ?

@TedDriggs
Copy link
Collaborator

Yes, I will do one this week when I have time.

@TedDriggs
Copy link
Collaborator

@bew I have now published 0.20.2 with this change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants