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

Don't require that @inbounds depends only on local information #54270

Open
wants to merge 5 commits into
base: master
Choose a base branch
from
Open
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
9 changes: 4 additions & 5 deletions base/essentials.jl
Original file line number Diff line number Diff line change
Expand Up @@ -851,11 +851,10 @@ end

Using `@inbounds` may return incorrect results/crashes/corruption
for out-of-bounds indices. The user is responsible for checking it manually.
Only use `@inbounds` when it is certain from the information locally available
that all accesses are in bounds. In particular, using `1:length(A)` instead of
`eachindex(A)` in a function like the one above is _not_ safely inbounds because
the first index of `A` may not be `1` for all user defined types that subtype
`AbstractArray`.
Only use `@inbounds` when it is certain that all accesses are in bounds. In
Copy link
Member

@stevengj stevengj Apr 26, 2024

Choose a reason for hiding this comment

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

Suggested change
Only use `@inbounds` when it is certain that all accesses are in bounds. In
Only use `@inbounds` when you are certain that all accesses are in bounds (as undefined behavior, e.g. crashes, might occur if this assertion is violated). In

Maybe just change it to "when you are certain". Basically, it's up to the code writer to decide what level of certainty they are comfortable with (e.g. "I'm certain as long as users don't break my API abstractions", or even "I'm certain because this is throwaway code and I'm only passing 1-based arrays today"). I think that subsumes @Keno's comment without opening a can of worms with phrasing about "public API".

particular, using `1:length(A)` instead of `eachindex(A)` in a function like
the one above is _not_ safely inbounds because the first index of `A` may not
be `1` for all user defined types that subtype `AbstractArray`.
"""
macro inbounds(blk)
return Expr(:block,
Expand Down