You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently @view always returns a SubArray, even when indexing with a scalar:
julia> x =1:31:3
julia>@view x[1]
0-dimensional view(::UnitRange{Int64}, 1) with eltype Int64:1
OTOH, @views returns the element when indexing with a scalar (as documented):
julia>@views x[1]
1
The behavior of @views sounds more consistent with plain getindex, and generally more useful. Rather than changing @view, @mbauman suggested deprecating it in favor of @views.
See #23051 (comment) for an example where the behavior of @views was more natural (but participant to the discussion seemed to be aware of its existence, so we ended up checking the index type manually).
(More radically, one could wonder whether view itself should behave like getindex when indexing with a scalar, and return the element rather than a view. Though that would be problematic if the goal was to mutate the parent array.)
The text was updated successfully, but these errors were encountered:
I think we can close this; @view and @views have different purposes. @view is just an alternate syntax for calling view, while @views is a transformation for performance.
Currently
@view
always returns aSubArray
, even when indexing with a scalar:OTOH,
@views
returns the element when indexing with a scalar (as documented):The behavior of
@views
sounds more consistent with plaingetindex
, and generally more useful. Rather than changing@view
, @mbauman suggested deprecating it in favor of@views
.See #23051 (comment) for an example where the behavior of
@views
was more natural (but participant to the discussion seemed to be aware of its existence, so we ended up checking the index type manually).(More radically, one could wonder whether
view
itself should behave likegetindex
when indexing with a scalar, and return the element rather than a view. Though that would be problematic if the goal was to mutate the parent array.)The text was updated successfully, but these errors were encountered: