-
Notifications
You must be signed in to change notification settings - Fork 89
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
For generic structs, apply type bounds in impl rather than requiring on base #91
Comments
See rust-lang/rust#26925 for rationale behind behavior of built-in traits. I'm comfortable with that behavior for |
* Builder impl block is now bounded for when generics implement Clone, rather than requiring that declaration on base type * Updated unit tests in core * Added integration test in derive_builder/tests
@TedDriggs Ok, cool. :-) We don't ever emit |
Improved type param bound expressions (#91)
@TedDriggs Can we close this and track the remaining EDIT: Or maybe keep it open until the next release... :-) |
My inclination is to close it and discuss |
Released with 0.4.7. |
If you run
cargo expand
on this code:You'll see that the generated
Clone
impl has a type bound requiring thatT: ::std::clone::Clone
:This may be possible for the generated builder impl as well: Inherent impl blocks are allowed to have trait bounds beyond what is declared on the base type. Doing so would better align to the standard library and would be slightly more ergonomic.
Implementation Considerations
Clone
type bound should not be emitted when using theowned
builder pattern.Default
type bound should not be emitted for generic fields with an explicit default expression.Update: Turns out that the compiler is perfectly happy with duplicate type bounds:
That makes this quite a bit easier.
Update 2: The compiler makes another simplifying assertion:
It requires all generic type params implement
Clone
, rather than all field members' types.In this code, it requires
U: ::std::clone::Clone
, rather than adding awhere
clause which would constrain theDoubler
. This is a little surprising to me, but I suspect it makes life easier since it means there isn't a need to determine which fields reference the various generic types.The text was updated successfully, but these errors were encountered: