Re:How an Engineering Company Chose to Migrate to D
by hmottestad on Wednesday June 20, 2018 @11:44AM
(#17356433)
Maybe "access to variables" means write access. I know that in Java variables referenced by a lambda need to be final.
[ Parent
| on HN ]
Re:How an Engineering Company Chose to Migrate to D
by oconnor663 on Wednesday June 20, 2018 @11:47AM
(#17356467)
Here's a tweak to the Go example above that demonstrates writing: https://play.golang.org/p/H9vCt93Qz2B
Here's a Rust version that does the same (without heap allocation!): https://play.rust-lang.org/?gist=bb5406062970b62088d58fb8a9f...
Re:How an Engineering Company Chose to Migrate to D
by eptcyka on Wednesday June 20, 2018 @03:41PM
(#17358992)
In Rust's case, this becomes far less practical as soon as the closure's return type does not implement the Copy trait.
Re:How an Engineering Company Chose to Migrate to D
by oconnor663 on Wednesday June 20, 2018 @04:36PM
(#17359511)
Here's an example that does something similar with Vec's: 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.
Re:How an Engineering Company Chose to Migrate to D
by steveklabnik on Wednesday June 20, 2018 @11:49AM
(#17356481)
Write access works. 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.