These are Rust's rules for the Borrow Checker

These are Rust's rules for the Borrow Checker.
Isn't the first rule really just RAII from C++? That would mean RAII is sufficient to stop use after free bugs, right?
And the second rule stops data races, but data races are not necessarily a bug.

Attached: rust.png (981x278, 40.84K)

>Second, you may have one or the other of these two kinds of borrows, but not both at the same time:
can you read op?
absolute state of 4chin nowadays
2nd rule of only 1 mutable reference prevents UB due to strict aliasing and iterator invalidation

no. in rust if you try
let mut foo = String::from("fuck op");
something = bar(&foo);
else = bar2(&foo);

it won't compile

No. The following is valid C++. Note that the function returns a reference (borrow) to something that's destroyed at end of function.
int& f() {
std::vector v{0};
return v[0];
}

>Isn't the first rule really just RAII from C++?
lol what? no?

this is why Any Forums should never be allowed to comment on the rust programming language

Thanks that makes sense.
What about the heap? Would forcing return by value on the stack, and RAII on heap avoid use after free bugs?

Memory safety janny filters another one.

Like, what's the use case for returning a pointer to stack memory addresses?
If a language just totally disallowed returning a pointer to stack memory addresses (but allowed heap for obvious reasons), what exactly would be lost?

>what exactly would be lost?
Nothing. In the example, the reference is pointing to heap though (assuming no small size optimization).

>having to ask permission to "borrow" resources from your computer

Attached: smug kim.png (177x144, 28.89K)

built for gcc

Oh I see, I'm used to pure C so I assumed that std::vector would be all on stack (like an array) or all on heap - but the header is on stack and the elements are on heap by default, which seems like a bad idea
If the object was allocated purely on heap though, there is no problem right? The "name" would fall out of scope, but the object itself would still be alive right?

Not him but Rust has stack allocated arrays too, vector is a different data structure.

C++ std containers use RAII, which means the heap memory gets deleted (ie freed) right when the "name" exits scope.
You could replace std::vector with std::unique_ptr (which is just a pointer to heap).

>You could replace std::vector with std::unique_ptr (which is just a pointer to heap).
* and the example would work just the same: return a reference to freed memory.

lol imagine using a non GC'ed language
sorry virgins I spend my time actually solving problems instead of keeping track of memory

So if you disallow pointer returns completely, and combine with RAII, then it mimics the first rule for the Rust Borrow Checker right?

Pretty much, yes. You still need to be careful while writing copy/move constructors for classes that use heap though, or just use std containers that handle the difficult stuff for you.

I see, and the main difference between this and pure C is thus that malloc() would have infinite lifetime unless you manually free (instead of having scope based rules like RAII or Rust), and if you lose reference to the allocated memory without freeing, it just leaks and takes up RAM pointlessly

Yes, that's right.
Long-running C programs usually end up manually doing RAII or allocate resources right at program start.