# Modifying a moved field

**URL:** <https://internals.rust-lang.org/t/modifying-a-moved-field/724>\
**Category:** Uncategorized\
**Created:** [October 28, 2014, 7:27am UTC](https://internals.rust-lang.org/t/modifying-a-moved-field/724 "2014-10-28T07:27:35Z")\
**Posts on this page:** 1\
**Showing post:** 6

<div class="post-metadata">

**Author:** ![nikomatsakis](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/nikomatsakis/32/5410_2.png) [@nikomatsakis](https://internals.rust-lang.org/u/nikomatsakis)\
**Post date:** [October 29, 2014, 7:25pm UTC](https://internals.rust-lang.org/t/modifying-a-moved-field/724/6 "2014-10-29T19:25:51Z")

</div>

In general moves are tracked at a pretty narrow level of granularity. We intend to eventually permit you to “fill” both fields back in and then use the structure again. I guess that doesn’t work today. I have to go look again at the moves code, but I think in general one of the things I’d like to pursue post 1.0 is extending the type system to deal better with things that have been moved from (in particular I want to support moves out of `&mut` pointers, so long as you restore the value before doing anything fallible). Anyway I think this example more-or-less falls out of treating things in a general way, though you could imagine rules that say “if you move `f`, you can never again touch any subfields of `f` without restoring `f` as a unit”.

---

_[View the full topic](https://internals.rust-lang.org/t/modifying-a-moved-field/724)._
