4 ms·

Maybe "access to variables" means write access. I know that in Java variables referenced by a lambda need to be final.

• oconnor663 8y ago
  Here's a tweak to the Go example above that demonstrates writing: https://play.golang.org/p/H9vCt93Qz2B https://play.golang.org/p/H9vCt93Qz2B Here's a Rust version that does the same (without heap allocation!): https://play.rust-lang.org/?gist=bb5406062970b62088d58fb8a9fe6d98&version=stable&mode=debug https://play.rust-lang.org/?gist=bb5406062970b62088d58fb8a9f...
  • eptcyka 8y ago
    In Rust's case, this becomes far less practical as soon as the closure's return type does not implement the Copy trait.
    • oconnor663 8y ago
      Here's an example that does something similar with Vec's: https://play.rust-lang.org/?gist=7a4ed9098a53831195c5189ba9cd904f&version=stable&mode=debug https://play.rust-lang.org/?gist=7a4ed9098a53831195c5189ba9c... I think the real nastiness happens if you want to have more than one closure over the same variables, when those variables aren't Copy. Because then when you try to `move` them in, the compiler yells at you. At that point you have to resort to putting them in an `Arc<Mutex>` or something like that. But that's par for the course with Rust: the compiler is preventing you from creating multiple mutable references to the same object.
• steveklabnik 8y ago
  Write access works. https://play.rust-lang.org/?gist=573c941b91657bb0dbac80c33d073a2c&version=stable&mode=debug https://play.rust-lang.org/?gist=573c941b91657bb0dbac80c33d0... Once "non-lexical lifetimes" lands, the inner scope won't be necessary. That may have tripped the OP up.