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.
Objective
BoxReflectforBox<T>whereT: Reflect#6098 , which is held for quite a long time.Solution
For most methods, we are able to use inner wrapped reflect value directly through
self.as_ref()and rely on that when the semantic seems to be valid.However there are several design choices that I made by my own and may need more discussion.
My preference is to minimize the changes so hopefully I don't introduce too many bugs in this PR.
So:
Boxnot aValuebut aTupleStruct. Internally within Rust std, theBoxis a tuple struct as well but over both the contained value and the allocator. I was saving the allocator part unless it is really needed in the future. In the previous PR (namely implementReflectforBox<T>whereT: Reflect#6098 ), it introduces a new kind calledWrapper, my guess is that, the reason it introduces this new kind is to allow access to the internal value contained in the Box but not be confused with the real other kind likeTupleStruct. I'm solving this with the next choice, so I'm presuming it is OK to stayTupleStructfor Box.fn as_inner(&self) -> Option<&dyn Reflect>is introduced withinReflecttrait and returnsNoneby default for all non-boxed type. This distinguishesBoxtype with all other normalTupleStructtypes. By this way, we know if a type is aBox-ed or not. The drawback is that, the complexity of theReflectis increased.This should not be the only way of implementing
ReflectforBox<T>.We might need a bit discussion on this to make sure if these design choices are reasonable enough.
Also, if I'm wrong about the
Wrappertype in #6098 , there's still things that I ignored, I'm happy to rethink my design.(As a side note, I'm not sure if this is OK to re-implement a proposed PR. If I'm wrong about this, please tell me what is the better way of doing this, I'm OK to change.)
Changelog
Reflecttrait implementation forBox<T>when T implementsFromReflectandTypePathtrait.