-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
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
split Base.lastindex
semantics, avoid sentinel value
#34697
Comments
I forgot to mention, if a collection can't be |
Further motivation for this semantic split: if e.g. Perhaps it would be not a pun to use [EDIT: added more links 2020-aug-5] |
There's a third very prominent role for julia> Meta.@lower A[end]
:($(Expr(:thunk, CodeInfo(
@ none within `top-level scope'
1 ─ %1 = Base.lastindex(A)
│ %2 = Base.getindex(A, %1)
└── return %2
))))
julia> Meta.@lower A[end, end]
:($(Expr(:thunk, CodeInfo(
@ none within `top-level scope'
1 ─ %1 = Base.lastindex(A, 1)
│ %2 = Base.lastindex(A, 2)
│ %3 = Base.getindex(A, %1, %2)
└── return %3
)))) Returning 0 for an empty collection is very helpful for syntaxes like |
It seems like
lastindex
serves two roles that are tempting to conflate, but could possibly benefit from being split up."what is the index of the last element"
This is what
lastindex
currently does, except for when the collection is empty (so there is no last element)Possibly it should return
nothing
or throw aBoundsError
, but 0 is really the only reasonable choice because of the second use:"if I
push!
ed another element, what would the index to it be, minus 1"This is the use case I find myself wanting, and it's simple enough to do
lastindex(...) + 1
as can be found in many uses oflastindex
e.g.julia/stdlib/Base64/src/buffer.jl
Line 21 in 4b6ab68
The behavior of
lastindex
can't be changed until 2.0, clearly. But if the distinction I am making above is useful, then we should have a separate function, possiblynewindex
. Having two closely related functions might be confusing, and users might not understand the big deal, since it's easy enough to do+ 1
or- 1
depending on what you need, but I would argue that splitting up functions like this issue suggests makes it easier to handle boundaries / edge cases.To be clear,
The text was updated successfully, but these errors were encountered: