3 ms·
Yeah, it looks like the author started playing around with D and writing a Pascal to D compiler for the migration, then did the evaluation with a "requirements"
by lambda 8y ago
Yeah, it looks like the author started playing around with D and writing a Pascal to D compiler for the migration, then did the evaluation with a "requirements" list that seems fairly heavily weighted towards D and their approach to translation by doing a simple recursive walk of the Pascal parse tree and outputting equivalent D, then decided to go with what they had already started working on.
Rust does support nested functions that don't close over their environment, and has a separate syntax for closures which do, and closures can either move or borrow their captured variables. This makes it a bit harder to write a translator that produces good, idiomatic results; you could always use a closure that borrows the closed over variables, which I think matches the Pascal semantics, but that would mean the code would look a little odd for cases in which you had a nested function just to factor out some functionality and didn't need the closure.
fn main() {
let a = 10;
fn function() {
println!("Hi!");
// println!("a is {}", a)
// fails with:
// can't capture dynamic environment in a fn item
// use the `|| { ... }` closure form instead
}
let borrow_closure = || println!("a is: {}", a);
let move_closure = move || println!("a is still: {}", a);
function();
borrow_closure();
move_closure();
}
- WalterBright 8y agoD nested functions are defined exactly like regular functions, including all attributes, parameter types, etc. There's nothing new to learn. My experience as a language designer is that syntax matters, and leveraging the users' existing knowledge is worthwhile.