The free variables that can be used come from the enclosing scope and are ‘closed over’ when used in the function.
they don’t cause the kinds of error-at-a-distance problems that inferring named function types can Closures
When I read the chapter of the closure.
What's the meaning of 'free variables'?
What's the meaning of " are ‘closed over’ when used in the function ?"
What's the meaning of 'error-at-a-distance'?
Someone can give some examples?
By the way, I feel that Rust has a lot of tools, but lacks guiding ideology (e.g. In python, Everything is object, So all the features, all the tools, all the mechanisms are in a unified model, which is very helpful to understand, to learn, to use. that's elegant.).
It has features about procedure programming, OOP, functional programming, but if i adopt OOP, i would found Java is more convenient and productive. What would it be like ?
So what attracts you to this language, just it's safety?
thanks for help.
Thanks for the feedback, I'm sure @steveklabnik and other doc contributors will find your opinion useful for improving the docs. Free variables are mentioned only in the introduction and never again, it would be better to remove that term from the text.
I see you are not a native speaker (neither am I). Closures originated in functional programming which has heavy scientific influence. This influence brings some strange vocabulary that can make learning a bit harder. Answering your questions:
Free variables are variables that are used in the closure but are not defined in the closure.
I think "closed over" variables is another way of saying free variables.
Error-at-a-distance is when the error compiler shows an error at a place in your code, but the real cause is far away from where the error is shown.
If Rust has an "ideology" it's being safe and fast, just as it says on the homepage. Rust is not an object oriented language, as the FAQ say, "Not everything is shoe-horned into a single abstraction", everything being an object makes some things simpler but can also be limiting.
Personally I like rust not only because it's fast and safe, most modern languages are fast enough and safe enough for my purposes. However I love it's type system (generics, enums, traits, it's a box full of delicious, expressive candy), the emphasis in compile time checking (I trust no code, especially mine), it's community and totally open development process and the fact that it's new, I like shiny new toys. I hope you find your own reasons to enjoy rust!
My English is horrible:stuck_out_tongue:
Thank you for your detailed reply,which is very useful to me.
Since so many people like Rust, I still need to study hard, maybe someday, it will give me a surprise.
Thank you again for your help.
I started using Rust because I wanted a language that compiled to native code. I did do C/C++ years ago, but I feel the concept of a separate header/body file is outdated after doing JAVA programming for so long. When going back to C++ i kept feeling like I had to define everything twice, once in the header file and once with the actual implementation.
So really I was just looking for a "modern" compile to native code language without the baggage of a language that had to be able to compile "quickly" on a computer built in the 70s.
I love the fact that the compiler determines the variable types, giving me the feel of the un-typed languages but still having the safety/speed of a typed language. The enums and match commands also have a certain elegance to handling returns from function calls.
I'm still trying to get a feel for what all the features mean for a rust application and how that effects the overall design.
The rust data ownership model is interesting and I do agree it helps keep bugs out of your code. I have collided with it, usually around debug logging when I want to log the result of an operation, but ownership of a variable has been given away. Which means if debugging is enabled, i pass a cloned instance so I can still log it's value along with the result, but if logging isn't enabled don't do the clone to avoid the overhead.
