Skip to content

RFC: Mark the read-write variants of the NumPy iterators unsafe #279

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

Merged
merged 1 commit into from
Mar 3, 2022

Conversation

adamreichold
Copy link
Member

For the same reason that PyArray::as_array is unsafe, i.e. the lack of control over aliasing even for safe Rust code producing multiple iterators.

(I am not totally sure whether this is the right thing to do as I would mark them safe again in #274 after adding dynamic borrow checking but it appears slightly inconsistent as it is.)

@adamreichold
Copy link
Member Author

Needs a changelog entry...

@adamreichold
Copy link
Member Author

(I am still working on the copy-editing of all doc comments but I think this can wait for point releases. I would however be glad if this PR and possibly its follow-up #280 could be part of the 0.16 release if review bandwidth suffices.)

@adamreichold
Copy link
Member Author

adamreichold commented Mar 3, 2022

I would be willing to stick out my neck here and merge this without further review to reduce the review load for 0.16 to #280 and #283. I think not marking these methods is incorrect for the same reason that PyArray::as_array(_mut) are unsafe, i.e. Rust code could create multiple iterators each consuming just &PyArray<T,D>, thereby handing out aliasing exclusive references and do so without any errors in the calling Python code.

Copy link
Member

@davidhewitt davidhewitt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 ok, lgtm! I think at this point it might be practical to assume that I will have very limited time to put deep thought into rust-numpy for a while until baby whirlwind passes. Perhaps feel free to take authority on design decisions as you feel comfortable to move the project forward? And ping me / request review on topics you'd like me to spend time thinking on. Otherwise I fear I may become a blocker for the next few months.

@adamreichold adamreichold merged commit 126a9e7 into main Mar 3, 2022
@adamreichold adamreichold deleted the unsafe-mutable-iter branch March 3, 2022 20:19
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

Successfully merging this pull request may close these issues.

2 participants