Disable @inbounds for non-0-based arrays

[PallHaraldsson]

In light of recent discussion, blog post about the (un)reliability of the Julia ecosystem, maybe it's best to simply disable @inbounds but only in that case. Already debugged code for 1-based (what Julia only had once) will thus still work, and be as fast, but OffsetArrays.jl (for now) will be second class (we can follow-up to fix that).

That's basically the request, what follows is discussion if it's actually possible. Taking the example from the docs:

  function sum(A::AbstractArray)
      r = zero(eltype(A))
      for i in eachindex(A)
          @inbounds r += A[i]
      end
      return r
  end

I think @inbounds there only "sees" r += A[i] so it's missing the context, that eachindex is used, i.e. in that case no bound checks would be safe. I'm ok with that, it would put pressure on the compiler figuring it out. Had 1:length(A) been used instead the code would have been wrong, but only for non-1-based. Would the code have been better with the macro at @inbounds for and then it could be disabled in fewer cases?

Does the macro see the type of A? I'm not sure it does, but even if not, I think it could generate code that does see the type, and can handle it conditionally, so shouldn't be a problem.

[KristofferC]

It is up to the package to decide what to do when it sees an inbounds notation. You can open the issue on whatever package you want to to change the behavior in.

[PallHaraldsson]

I'm confused, it's not up to "the"/a package.

Yes, it's up to the package author to decide to use @inbounds as some did, e.g. Distributions.jl which was correct until Julia 1.4 changed the rules of correctness. Yes, you could take out inbounds of any one (or all packages), but it would be bad for all regular users, or fix any one (as with still pending fix), here: JuliaStats/Distributions.jl#1550

But this proposal was to surface brokenness in all packages in by changing Julia, which no one package can do.

[oscardssmith]

it's up to the package implementing the array type. i.e. OffsetArrays.jl could make @inbounds a no-op.

[KristofferC]

@inbounds can elide a @checkbounds block but like Oscar says, it is totally up to the package to opt into that.

[PallHaraldsson]

OffsetArrays.jl could make @inbounds a no-op.

Ok, makes sense to me now. That package could do it, I suppose. It would have to override the macro, for its users, but the changed macro would also apply to all users, of e.g. regular 0-based arrays (I don't want anything disabled for them, but that seems possible for with the same conditional logic I'm proposing).

There are pros and cons to doing it a) there vs in b) Julia. It would only work with later versions of the package. And I sometimes see Pkg downgrade packages... it could be an unnoticed headache for users. On the flip-side if done in Julia then would only work in later Julia versions e.g. not in 1.6, as would work with a).

I'm not sure there are more similar packages we need to worry about (I know about e.g. StarWarsArrays.jl). I was thinking one changed macro would change all non-1-based, not just one particular such package. The major thing is making the new macro, I'm more relaxed about there to place it.

[Suavesito-Olimpiada]

It would have to override the macro, for its users

Actually, no. The bounds check section of the docs says:

The @boundscheck(...) macro marks blocks of code that perform bounds checking. When such blocks are inlined into an @inbounds(...) block, the compiler may remove these blocks. The compiler removes the @boundscheck block only if it is inlined into the calling function.

This means that the package implementing getindex may decide to not mark checkbounds with @boundscheck, then @inbounds will be no-op.

This change in a package is not reimplementing the macro, and won't affect other user except those that are using the package.