undefined

points

[-]

> The problem is that this still runs into complexity problems and does not scale to non-toy programs.

Right; that is why Rust's borrow checker was designed to be intraprocedural only. That obviously is a tradeoff of its own: now functions need to be annotated to convey information across function boundaries, and the annotations picked will influence what can and cannot be expressed.

> IMHO a middle ground with some annotations is realistic and would be far more convenient than a borrow checker when supported by good tooling.

I'd be interested in seeing what such a middle ground looks like, particularly in respect to what tradeoffs it makes!

by uecker12 minutes ago|

parent|

[-]

I don't know yet. My current expectation from what I have seen is that lifetime analysis can be done fully automatic for most C code as long as it can be done independently from other program state, i.e. the checker has to reason only about the state of pointers and not also simultaneously about all other variables. I have seen quite promising work on this.

by eddifyoppor1 hours ago|

prev|

[-]

A borrow checker can do more harm than good in some cases. An arguable example of that is https://fasterthanli.me/articles/a-rust-match-made-in-hell .

Your background is C as I understand it, and C does not really have issues with temporaries as they are known in C++ and Rust.

My understanding:

C compound literals have invariable and relatively long lifetimes, namely to the end of the local block, and to shorten those lifetimes, one has to put the expression with the compound literal in a new, smaller local block. The advantage of those long lifetimes is that lifetimes are typically long enough for it not to cause issues in C. C also does not have RAII.

Both C++ and Rust have varying lifetimes of temporaries and have RAII. Both C++ and Rust have had messes with lifetimes, C++23 changed lifetime rules for the range-initializer expression of range-based for-loops, and Rust changed lifetimes rules in Rust 2024 such that whether a specific piece of Rust code has a deadlock or not, depends on its edition, and editions are generally not specified per-file but per-project.

Temporary lifetime extension can be tricky for both developers and language designers.

But the borrow checker can make it worse in some situations, for it can push developers towards bug prone designs that have greater risks of deadlocks, just to satisfy the borrow checker. The borrow checker also mostly enabled the language designers to go wild with lifetimes, since they did not have to worry as much about UB as long as they were in the not-unsafe subset, so the issues with deadlocks might be worse in practice than if they had been more careful and restrained with lifetimes.

It can also be very subtle whether Rust code has deadlocks or not. One of these Rust programs has a deadlock, the other does not. The difference is the presence and absence of temporary lifetime extension, as per the "{}".

https://play.rust-lang.org/?version=stable&mode=debug&editio...

by uecker31 minutes ago|

parent|

[-]

I guess this must be the fearless concurrency I am hearing about. /s

In general I understand why people like RAII and the idea of not worrying about pesky details such as resource cleanup is appealing, but the philosophy in C is that the compiler should not do such things behind your back and perhaps this is sometimes valuable. I like this more because things are explicit and visible and I rather want to have tools that tell me that what I do is correct rather than a language that does a lot of things implicitly behind my back (especially if this is correct 99% of times but sometimes surprisingly is not). This is why I am not a fan of C++ nor Rust. Thank you for the nice example illustrating issues in Rust arising from this.