Expand ZeroFrom to cover cases where attrs can borrow #3770
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds
zerofrom(may_borrow)
, which allows derivingZeroFrom
on generic types which have parameters we care about borrowing.I'm not happy about the terminology in ZF, we have a couple things talking about the same thing:
zero_from
, and the type parameter ofZeroFrom
'zf_inner
, which is the lifetime of the "C type"lifetime_ty
, which is the C type version of the field type. usually the type with'zf_inner
replacing its main lifetimeI'd like to come up with a nice name for these things we can make consistent. I try to document this a bit better here though.
I'm doing this in an attempt to start using generics in datetime symbols code more; I have #3767 open but I want to try and clean up the rest.
If this approach works I plan to do something similar in Yoke.
may_borrow
can't be applied directly to type parameters due to rust-lang/rust#114393. This code is future-proof for whenever that upstream bug is fixed.Part of #3771