-
Notifications
You must be signed in to change notification settings - Fork 4
Feat: Allow lifetime for bounds in non-binded generic params #107
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is indeed a very strange quirk of Rust!
Please add a changelog entry as well.
Otherwise LGTM!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Run
cargo +nightly fmt
. - Changelog entry.
Completely missed the changelog request! Sorry about that. Should be good to go now I think |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Completely missed the changelog request! Sorry about that.
All good! I know how it is :)
Will wait for #108 before merging.
Co-authored-by: daxpedda <[email protected]>
Co-authored-by: daxpedda <[email protected]>
e6acb63
to
c882e1c
Compare
Hey @daxpedda was wondering if there are any plans to cut a new release soon. We're currently working on a private registry so we aren't blocked on this or anything, but just wanted to ask since its been a while since the last one. Thanks! :) Edit: just noticed the new PR... 🤦 that pretty much answers my question lol. |
It's currently not possible to use higher rank trait bounds without providing custom predicate type bounds. Our particular use case is enabling "trivial bounds" without requiring the nightly feature. For context: rust-lang/rust#48214 (comment)
For example:
This is useful for adding perfect derives to macro-generated structs.
I'm not fully sure whether having a HRTB should make
has_type_param
return false or not. I think its probably fine to keep it returning true since adding one that's not used doesn't change the behavior; it should still be derivable w/ the standard derive. Users can always make type aliases to get around this anyways if they disagree lol.