Could you explain what that means and how it benefits compared to common languages discussed here? Those of us from imperative backgrounds mainly read these threads to learn ideas that we might move into such languages.
But most languages have had a solution to the resource problem at least as far as memory is concerned for a long time: garbage collection. It has huge advantages over Rust's approach, in that you can basically not think about RAII or ownership at all; as long as you're not actively holding on to an object, the memory will get reclaimed for you.
But this doesn't solve the problem for other resources like files, since when a file is closed actually matters semantically. You don't want to just let the garbage collector decide when to shut down a tcp connection.
So what the gp is suggesting is, it would be nice to have a language that uses GC where it makes sense, as it's generally easier to work with, but also provides sane mechanisms for releasing resources like files and sockets.
At least in some languages this is not an issue if one is able to use higher order functions, with bonus points if they allow for trailing lambdas.
So if it is possible to organize the application architecture as regions where the resources are supposed to be valid, then one can manually get rid of such resources.
Of course, this might not always be possible, and there is the caveat that one needs to remember to apply such patterns.
Which is easier if it can be imposed via the type system.
I am afraid you are talking nonsense. Higher-order functions make verification harder, not easier, because they hide the point at which control flow is transferred from one module to another. This is backwards, because this point should be prominent, in big neon letters, precisely so that you can tell exactly when a resource stops being available, or when an invariant goes from being “your responsibility” to “someone else's problem”.
with_file "hello.txt" (fun fd -> (* do stuff *) )
It's certainly not "verification" in any formal sense, and the type system can't help you there any more than it can in c++.
But this is a perfectly reasonable pattern.
Except for the part where destructors are meant to be called no more than once per object, at the end of its lifetime. All that you can guarantee is that `with_file` doesn't call the destructor more than once. But that's not terribly interesting.
But again hence the value of having the lifetime of the object enforced by the type system.