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

Dataset::rasterband doesn't follow Rust mutable reference rules. #450

Open
metasim opened this issue Oct 3, 2023 · 2 comments
Open

Dataset::rasterband doesn't follow Rust mutable reference rules. #450

metasim opened this issue Oct 3, 2023 · 2 comments

Comments

@metasim
Copy link
Contributor

metasim commented Oct 3, 2023

Currently, the following compiles, but the test fails:

#[test]
fn test_mut() {
    let dataset = Dataset::open(fixture("tinymarble.tif")).unwrap();
    let b1 = dataset.rasterband(1).unwrap();
    let before_desc = b1.description().unwrap();

    {
        let mut also_b1 = dataset.rasterband(1).unwrap();
        // Arbitrary mutation
        also_b1.set_description("smash").unwrap();
    }

    let after_desc = b1.description().unwrap();

    assert_eq!(before_desc, after_desc);
}

Given we never request a mutable reference to Dataset, one could argue you should never be able to get a mutable reference to an owned, constituent component of the Dataset, as we have done here.

@jdroenner
Copy link
Member

yes thats right. It was probably overlooked at some point. We could introduce something as an OwnedRasterband.... However you don't even need to mutate something on purpose. Using RasterIO can (and will in many cases) modify some global variables.

@metasim
Copy link
Contributor Author

metasim commented Oct 3, 2023

This is how I'd propose we solve it (assumes foreign-types crate applied to Rasterband.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants