I definitely see it being a nice feature that Rust programmers should be able to specify. But it also seems like it could be automated. If the variable is going to be used again, don't destroy it within the function instead of forcing a borrow. Why can't mut be mutable by default? And a warning if it could be immutable. I'm sure a few other things.
It is quite nice from the security and safety point of view and because it seems like Rust magically catches most of your bugs. If you can make it through the compiler, your code usually works. And it forces the programmer to think about these things. Which is awesome, but I guess my point is, it does scare some people away. What if we had a beginner and advanced Rust, and similar to making code unsafe, you could mark it as 'lazy' or something where things could be automated?
Mostly curious to hear thoughts. I personally would always want the current/unlazy version of Rust since my current project needs high security. And I guess from a security perspective, nice to know libraries I'm calling do the same.
But might win over some people currently complaining about the learning curve.
You may be excited to know that implicitness seems to be more or less a core focus of the roadmap for rust this year (but don't take it from me!).
Personally, I think it's a tricky subject. Implicitness makes the initial curve shallower, but also makes the later curve much steeper; eventually, the abstraction leaks.
If the variable is going to be used again, don't destroy it within the function instead of forcing a borrow.
What do you mean? If a variable is allocated on the stack then it will always perish once the function returns. Your options are to either pass in a &mut to designate where the variable is to be stored, or to create the variable on the heap.
The borrow checker already knows whether or not a variable will be reused and already knows whether the function will need to modify it (though I'd leave that one explicit). If it didn't, it couldn't throw an error. So I'm just saying that it doesn't need to be explicitly specified. The compiler can just smartly decide in the background whether to borrow the variable or destroy it after use.
It is correct that the compiler could infer much more information than it currently does. But the experience has shown that too much implicitness introduces bugs and makes software significantly harder to maintain. Some parts of the language, e.g. explicit return types, do not only help readability, but can even be seen as forced documentation. Having worked with a lot of languages and frameworks with much implicitness, I do really like the way rust handles this topic, especially regarding variables and borrowing.
If the variable is going to be used again, don't destroy it within the function instead of forcing a borrow.
The rules are simple -- a pass by value means passing ownership. This isn't going to change, nor should it. The existing behavior is very helpful as it clearly states the intent of each line of code. No need for interpreting what may be happening based on context. Explicitness is one of the features that you are signing up for when you invest into Rust.
Why can't mut be mutable by default?
Anything defined as mutable is already mutable. If you are referring to making let mutable by default, there's good reasons for why you must specify mutability -- mutability should be discouraged by default. Programmers need to more aware of what they are doing, as laziness encourages carelessness.
We don't want to inherit the same mistakes that C and C++ made. Most variables defined in your source code will never need to be modified, which is aided by the functional paradigm that makes initializing immutable variables in a single line of code very trivial. In the future, the immutability by default will lead to performance benefits as a result of avoiding pointer aliasing, in addition to the existing benefits that this provides to threaded software.
I guess my point is, it does scare some people away
If they aren't willing to go down the road of safety provided by Rust, it's either because they are young and lack experience / knowledge, or they are old programmers stuck in their ways. There isn't anything you can do about that so there's no need to worry about the stragglers.
For the inexperienced, after they've been burned enough by their own software and the software of others, they will long for a language like Rust. For the experienced that still see no point in Rust, there's nothing you can do except lead by example. With more Rust software and Rust software successes will come more interest in Rust, not before.