a way to track them
Yes, that’s what I’m suggesting. Injecting some kind of metadata that gets stripped at code gen time would probably work.
worse incremental compilation performance
Would it really be that significant?
without allocating everything on the heap
I’m talking about compile time.
Start with all of the known safe cases (basic types should be fine), then move on to more dubious options (anything that supports iteration). Then allow iterable types but don’t allow iterating over a mutable reference. And so on. If it’s a priority to loosen up the rules without sacrificing safety, surely some solutions could be found to improve ergonomics.
Or perhaps there could be some annotations to make a reference as “unsafe” or similar instead of just a block. If something is safe in practice but not verifiably safe, there should be a way to communicate that.
You want some annotations to break out of the safe subset of the language
The annotations would indicate that something unsafe is going on, so it’s like an unsafe block, but on a reference. That way it’s clear that it’s not being checked by the borrow checker, but the rest of the application can be checked.
I really liked the idea of an optional, built-in GC w/ pre-1.0 Rust where specific references could be GC’d. If that were a thing in modern Rust (and the GC would only be enabled if there’s a GC’d reference included), we could get a lot more ergonomics around things like linked lists.
I’m talking about compile time.
Start with all of the known safe cases (basic types should be fine), then move on to more dubious options (anything that supports iteration). Then allow iterable types but don’t allow iterating over a mutable reference. And so on. If it’s a priority to loosen up the rules without sacrificing safety, surely some solutions could be found to improve ergonomics.
If you want guaranteed safety then the borrowing rules are the most flexible as far as we know.
Just to give a couple of examples of how your idea might be flawed, what do you consider “basic types”? Are enums basic types? Then you’ve got an issue, because you might get a reference to the contents of an enum and then replace the enum with another variant, and suddently you’ve got a dangling reference. Would you prefer to prevent creating references to the contents of an enum? Then you’re more restricting than the borrowing rules.
Allowing iterable types but not iterating over mutable references is not enough for safety unfortunately. The basic example is getting a reference to an element of a Vec and then calling push on the Vec. This seems very innocent, but pushing on a Vec might reallocate its backing buffer, making the previous reference dangling. Again, would you prevent taking references to elements of a Vec? Then again you become much more restricting than the borrowing rules.
I really liked the idea of an optional, built-in GC w/ pre-1.0 Rust where specific references could be GC’d
That was just syntax sugar for Rc/Arc, and you can still use them in today’s Rust, albeit with slightly worse ergonomics (no autoclone for example).
