Is there a way to turn off the warnings "indexing with indices obtained from 'length','size' etc is discouraged in VSCode?

General Usage
1

I get that you want these warnings for package writers but this is an application using Base matrices and it’s never going to use any other matrices with exotic indexing and you can’t pass matrices as an argument to the app. So I don’t need to change my code to generic abstract indexing and the warnings are just a nuisance.

Is there any way to turn these warnings off?

Also on a more general note: now that the community has decided that “anything goes” as far as indexing is concerned, I think that the type hierarchy for matrices should be way more detailed and reflect the indexing sheme of a matrix type. For example for Base matrices it should become something like OneBasedIndexingMatrix{.,.} instead of just Matrix{.,.} and when the compiler/linter sees this it won’t issue these warnings if you just use one based indexing directly instead of eachindex.

1 Like
2

No, but there will be in the next release. Yes, disable the julia.lint.iter check in the settings.

3

But isn’t this a good reminder to just get into the habit of using eachindex? Why would one ever want to use 1:length(x)? Is it that the warnings are annoying for legacy code? (Personally, I never tolerate 1:length, even when it is operating on an Array defined right inside the code itself.)

I don’t know if this is the case, but perhaps it is easier to automatically disable bounds checking with eachindex than with 1:length?

Being able to disable linter messages is of course good in general.

2 Likes
4

Why should I be forced to change code that was written at julia 0.2 when matrices were always 1-based and eachindex didn’t even exist, that is working fine and is as generic as it needs to be (like I said : it’s never going to use anything other than 1-based indices). It’s not like I hardcoded that a matrix is alway s N rows/columns long! It’s flexible with length and type so that’s plenty of generic.

It’s not because Python refugees couldn’t wrap their heads around 1-based indexing and wanted 0-based indexing (offset indexing) that all of a sudden perfectly correct 1-based indexing is wrong! Ok I get that it actually serves a more general role now than just 0-base indexing (but that’s how it got started) and it’s good that it’s possbile for more exotic things but you shouldn’t force the more exotic corner cases on everybody else.

2 Likes
5

Since I didn’t argue for that (and you’re not being forced, anyway), I guess that is not for me to answer. Legacy code is different from new code, so removing the annoyance is reasonable.

It’s not an exotic corner case, though, but the general case.

1 Like
6

Nevermind, this check can be disabled with the julia.lint.iter setting.

1 Like
7

I dropped all 1:length(x) I had, but what do I do with a few 2:length(x) that are scattered in my code?

8

Here’s one approach:

julia> eachbutfirstindex(x) = Base.Iterators.peel(eachindex(x))[2]
eachbutfirstindex (generic function with 1 method)

julia> x = [5, 4, 3]
3-element Vector{Int64}:
 5
 4
 3

julia> for i in eachbutfirstindex(x)
         println((i,x[i]))
       end
(2, 4)
(3, 3)
9

perhaps: firstindex(x)+1:lastindex(x)?

3 Likes
10

Yeah, or, if it’s inside an indexing operation: x[begin+1:end].

11

The reason that I didn’t suggest firstindex(x)+1 as the starting index is that it would fail when firstindex(x) returns a CartesianIndex:

julia> CartesianIndex(1,1) + 1
ERROR: MethodError: no method matching +(::CartesianIndex{2}, ::Int64)
Closest candidates are:
  +(::Any, ::Any, ::Any, ::Any...) at ~/.julia/juliaup/julia-1.7.3+0.x64/share/julia/base/operators.jl:655
  +(::T, ::T) where T<:Union{Int128, Int16, Int32, Int64, Int8, UInt128, UInt16, UInt32, UInt64, UInt8} at ~/.julia/juliaup/julia-1.7.3+0.x64/share/julia/base/int.jl:87
  +(::T, ::Integer) where T<:AbstractChar at ~/.julia/juliaup/julia-1.7.3+0.x64/share/julia/base/char.jl:237
  ...
Stacktrace:
 [1] top-level scope
   @ REPL[2]:

I’m not sure how often this would arise in practice, though.

12

Another pattern for consideration:

for i in eachindex(x)
    i == firstindex(x) && continue
    ...
end
13

For multi-dimensional arrays, you can use firstindex(x, dim).

14

Is that assuming we’re iterating over a single dimension?

15

If it is intended as a replacement for ‘ordinary’ indexing, which is apparently in high demand, where you either do
for i in 2:length(x) or for i in 2:size(x, dim), then the former can be replaced with firstindex(x)+1:lastinde(x) and the latter with firstindex(x, dim)+1:lastinde(x, dim).

If you’re using CartesianIndices, you’ve already stepped outside of ‘old-fashioned Matlab style’ indexing.

2 Likes