I kind of agree.

In a way it is great the work being done by the Rust team, as many companies wouldn't bother with it.

It is already influencing the design decisions of other languages.

However it really needs to be more ergonomic, I for example have been bitten trying to call a method into self from inside a closure.

From logical point of view it was clear, the closure wouldn't outlive the object that owned it, but the borrow checker thought otherwise.

This is one of the use cases being solved by non-lexical lifetimes.

Actually, as the text of RFC makes clear in "What this proposal will not fix" section, this does not fix "self in closure" issue. Actually, "self in closure" is explicitly listed as an example.

Oh, I misread it, as I quickly browsed through it. :|

If you reread the text of the RFC, you'll note that this specific issues intends to be solved by potentially tweaking the algorithm for closure desugaring. It's a solvable problem, though independent of NLL.

I don't think the current algorithm is actual a barrier to practical use. The worst I've had to suffer for it is a few extra lines of code here and there. This RFC might make things easier to use, but if it fails in that, it doesn't really prove the concept is infeasible.

Why would that be? If rust proves the concept works, I'd expect more languages to try it.

It's very hard to retrofit the rules that the borrow check enforces onto an existing language. That's because the borrow check enforces "aliasing xor mutability", and basically all languages in wide use don't enforce that. Adding that to an existing language generally requires breaking backwards compatibility in fundamental ways.

For example, all non-immutable objects in garbage-collected languages (or similar features such as shared_ptr in C++) are incompatible with these restrictions. As another example, mutable global variables are generally incompatible with the semantics that the borrow check enforces.

That said, I could see analogous dynamic systems (rather than static ones as in the case of Rust) becoming more widespread. In fact, Transferables [1] in JavaScript are an example of one such system.

[1]: https://developer.mozilla.org/en-US/docs/Web/API/Transferabl...

I read the parent comment's "I'd expect more languages to try it" as meaning more new languages.

Really interesting point about Transferables, I hadn't seen that.

Hmm, what about wrapping everything in an Arc<RwLock<...>> and gradually removing the wrappers (and the extra method calls) from each variable, backtracking on compiler errors?

Swift is likely to adopt it but it a much more measured way, since everything is `shared_ptr` by default in that language. Relatively few languages have the combination of requirements and goals that makes Rust's approach obligatory and necessary.

So if it's successful we should see more of it but...we won't necessarily see many languages where it is as all-pervading as Rust.

Swift's tentative plan seems to be to have a level between regular swift and super unsafe swift with UnsafePointer and stuff where you can write fast, low level, but safe code like Rust.

In swift's case I'd think they would avoid too much complexity since the lifetime stuff won't be as pervasive as it is in Rust (so it can have more rough corners)

Given the current state of the borrow checker and how lifetimes are handled inside closures, essential for callbacks, I think in its current state anything close to Cocoa or Cocoa Touch would be quite hard to implement and use in Rust, unless it is full of Rc and RefCell everywhere.

Lifetime handling inside closures is planned to be fixed. (It is a different fix from this one.)