Remove IntoOwned#624
Merged
frankmcsherry merged 19 commits intoJul 15, 2025
Merged
Conversation
antiguru
approved these changes
Jul 15, 2025
Member
antiguru
left a comment
There was a problem hiding this comment.
I think this looks good. Left some comments, but let's merge soon.
Member
Author
|
Thanks for the review, and agree about wanting to land this where possible. I'm pretty confident that the path ends up in the intended state, and checkins are perhaps locally clarifying even if the final arc of the store isn't yet clear. :D |
Merged
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 PR moves the functionality of
IntoOwnedinto the types that first provide access to the owned and borrowed types. The goal is to remove the freestanding requirement that a reference type should implementIntoOwned, as this is generally hard to introduce if it does not already exist. On the other hand, it is relatively easy for a container to provide this functionality, as it only needs to wrap existing logic (assuming it exists; if not there is a different problem). The main distinction is that we are happy to create new containers, or wrapper containers, etc. but much less happy to create new types that they contain.There is a surprising amount of unmucking to do along the way, and this description will be updated with the narrative arcs if it is successful. For the moment, it is a draft PR revealing the work.