remove certain array elem moves for non-zeroing drop by pnkfelix · Pull Request #533 · rust-lang/rfcs (original) (raw)
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 andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation10 Commits2 Checks0 Files changed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
Summary
In order to prepare for an expected future implementation of
non-zeroing dynamic drop, remove support for:
- moving individual elements into an uninitialized fixed-sized array, and
- moving individual elements out of fixed-sized arrays
[T, ..n],
(copying and borrowing such elements is still permitted).
My only worry here is that I'd like there to be a way to get a by-value Iterator over a small, constant number of items without allocating (right now it requires Vec), and I worry these changes may prevent that.
This version of array indexing isn't useful for iterators, as it prevents access to all elements of the array except the one accessed. The problem with array iterators is that we can't have impls generic over integers.
@reem: It definitely doesn't prevent that. Look at how the by-value vector iterator is implemented.
It's not going to work well though, because you need to take the fixed-size array by-value... which is not going to scale at all.
I guess it is orthogonal to this RFC, but I imagined the implementation would take some form of &move [T] or otherwise use a reference under the hood.
@reem removing language features such as this now does not preclude making other independent additions in the future that would enable useful functionality.
The only issue I could see would be if there is some useful pattern that is allowed today that would be made invalid by changes in this RFC, but as far as I can tell (and as mentioned in the comments above) the example you describe cannot be expressed today.
@nikomatsakis please do bring this up with core team when you can.
Add link to prototype implementation.
Add note that destructuring bind is not affected by the change proposed here.
Account for change in type syntax from [E, ..k] to [E; k].
We've decided to accept this RFC. The precautions here are sensible and unlikely to have wide-spread impact on Rust code. If necessary, they can be lifted later, at the cost of more complex codegen.
Labels
Array related proposals & ideas
Proposals relating to the Drop trait or drop semantics
Term language related proposals & ideas
Type system related proposals & ideas