4 ms·
So for what it's worth, this blog post is mostly a technical deep dive for people who are very interested in the full details. From a UI perspective, I (and ma
by wycats 12y ago
So for what it's worth, this blog post is mostly a technical deep dive for people who are very interested in the full details.
From a UI perspective, I (and many others, including core team member Aaron Turon) have argued successfully that the vast majority of these details should be inferred from usage. So if you try to mutate something in a closure, the closure will adopt that requirement. If you want to capture a value by reference, you won't also be allowed to move the closure off of the stack.
In other words, the rules for closures will follow intuitively from the regular ownership rules, and you will never, in normal usage, have to be explicit about any of this.
This blog post was intended to explain in excruciating technical detail how it all works under the hood, and could have been clearer about the intended usage.