Skip to content
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

remove certain array elem moves for non-zeroing drop #533

Merged
merged 2 commits into from
Feb 5, 2015

Conversation

pnkfelix
Copy link
Member

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).

(rendered)

@reem
Copy link

reem commented Dec 20, 2014

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.

@arielb1
Copy link
Contributor

arielb1 commented Dec 20, 2014

@reem

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.

@thestinger
Copy link

@reem: It definitely doesn't prevent that. Look at how the by-value vector iterator is implemented.

@thestinger
Copy link

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.

@reem
Copy link

reem commented Dec 20, 2014

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.

@pnkfelix
Copy link
Member Author

@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.

@pnkfelix
Copy link
Member Author

@nikomatsakis can we get discussion of this at a meeting?

@pnkfelix
Copy link
Member Author

pnkfelix commented Feb 2, 2015

@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]`.
@nikomatsakis
Copy link
Contributor

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.

@nikomatsakis
Copy link
Contributor

Tracking issue rust-lang/rust#21963.

nikomatsakis added a commit that referenced this pull request Feb 5, 2015
@Centril Centril added A-array Array related proposals & ideas A-drop Proposals relating to the Drop trait or drop semantics A-typesystem Type system related proposals & ideas A-expressions Term language related proposals & ideas labels Nov 23, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-array Array related proposals & ideas A-drop Proposals relating to the Drop trait or drop semantics A-expressions Term language related proposals & ideas A-typesystem Type system related proposals & ideas
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants