-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
view(::Memory, ::UnitRange)
should not create a Vector
#54768
Comments
So what to do? Revert the |
I think for 1.11, a good enough solution would be to revert |
We do? Julia seemed to work fine before #52049. I reverted both |
Reverting sounds good to me for now. Also much less risky compared to adding a new function this late in the 1.11 release cycle. |
#53192 makes a straight-up revert convoluted so I had to resort to just unexporting |
Looks like the decision has been made; removing triage tag. |
I wasn't around to complain about #53896, but I think that PR was a bad idea. That PR made
view
worse at doing the regular job thatview
is used for, and repurposes it for a different job.might end up doing an unnecessary allocation depending on if you get a
Memory
(becauseVector
is a mutable struct). This means that any generic function that takes aview
at every iteration of a loop is in danger of accidentally performingN
allocations if it is passed aMemory
. For example:If you actually wanted a regular
SubArray{<:Memory}
, you cannot useview
for that and instead need to call theSubArray
constructor directlyThe only reason you'd want this to return a
Vector
instead of aSubArray
is if you wanted topush!
or otherwise resize the result, but it's generally not good practice to encourage people to writepush!(view(m, idxs), x)
because that'd normally error.I propose we remove this method before 1.11 drops.
The text was updated successfully, but these errors were encountered: