Skip to content
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

Allow to mutably query for immutable components #17141

Open
vil-mo opened this issue Jan 4, 2025 · 0 comments
Open

Allow to mutably query for immutable components #17141

vil-mo opened this issue Jan 4, 2025 · 0 comments
Labels
A-ECS Entities, components, systems, and events C-Feature A new feature, making something new possible D-Modest A "normal" level of difficulty; suitable for simple features or challenging fixes S-Needs-Design This issue requires design work to think about how it would best be accomplished

Comments

@vil-mo
Copy link
Contributor

vil-mo commented Jan 4, 2025

What problem does this solve or what need does it fill?

Related #17140

Often you want to lock end users from mutating component, while still having the ability to mutate it in the library internals. For example there is a Child and Parent relationship in the bevy_hierarchy #16662

Currently, this access only limited to the exclusive world access. Querying also can be an option

What solution would you like?

There are two ways of implementing it:
Add new smart pointer analogue to Mut that implements QueryData and only allows getting mutable access via unsafe methods

impl<'a, T> AssumeMut<'a, T> {
    /// - One of the following should be true:
    ///   - Either `T` is mutable, or
    ///   - `OnReplace` hooks and observers for that component on that entity should trigger immediately before the mutation
    ///     and `OnInsert` should trigger immediately after the mutation, or
    ///   - The user should uphold documented invariants of `T`. If no such documentation provided, it is impossible for the end user to uphold this.
    unsafe fn assume_mut(self) -> Mut<'a, T> {
        // ....
    }
}

Or

Change Mut smart pointer in a way to add assume_mut function if the type it points to is immutable.

impl<T> Mut<'_, T> {
    /// - One of the following should be true:
    ///   - Either `T` is mutable, or
    ///   - `OnReplace` hooks and observers for that component on that entity should trigger immediately before the mutation
    ///     and `OnInsert` should trigger immediately after the mutation, or
    ///   - The user should uphold documented invariants of `T`. If no such documentation provided, it is impossible for the end user to uphold this.
    unsafe fn assume_mut(&mut self) -> &mut T {
        // ....
    }
}

For that current implementation of immutable components does not work, since Mut is generic over any type, but DerefMut only should be implemented for mutable components. For that we can either

trait Mutable {}

impl<T: Mutable> DerefMut for Mut<'_, T> { /*..*/ }

Or

trait Mutability {
    type Mutability: ComponentMutability; // Rename would be desired
}

trait Component: Mutability { 
    // No associated `Mutability` type
    //...
}

impl<T: Mutability<Mutability = Mutable>> DerefMut for Mut<'_, T> { /*...*/ }
@vil-mo vil-mo added C-Feature A new feature, making something new possible S-Needs-Triage This issue needs to be labelled labels Jan 4, 2025
@IQuick143 IQuick143 added the A-ECS Entities, components, systems, and events label Jan 4, 2025
@BenjaminBrienen BenjaminBrienen added S-Needs-Design This issue requires design work to think about how it would best be accomplished D-Modest A "normal" level of difficulty; suitable for simple features or challenging fixes and removed S-Needs-Triage This issue needs to be labelled labels Jan 4, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-ECS Entities, components, systems, and events C-Feature A new feature, making something new possible D-Modest A "normal" level of difficulty; suitable for simple features or challenging fixes S-Needs-Design This issue requires design work to think about how it would best be accomplished
Projects
None yet
Development

No branches or pull requests

3 participants