The Latest Progress On Rust For The Linux Kernel

[cl333r]

And...? If that happens, RefCell will fail, in the same way every time. Which of these two functions will get there first is irrelevant, the point is that the situation will happen and RefCell will tell you where.

You didn't understand: one single function calls borrow_mut() onto the same instance of a RefCell object, let's call this function SuckMuhBalls(), but different callers into SuckMuhBalls() might call SuckMuhBalls() while said RefCell object is already borrowed or not, depending on this SuckMuhBalls() might succeed or crash the app. Hence the problem: how do you know all possible runtime function call paths into SuckMuhBalls() to make sure it never crashes the app?

[oleid]

Desired behavior for me, maybe not for you: removing items from a vector looping from end to start, removal decided based upon certain item criteria.

But that would not be aliased mutability. It would make more sense to talk about concrete code snippets.

[cl333r]

Want to bet how many pages it will take for him/her to realize that enforcing borrow semantics via an option standard library runtime mechanism is not the same thing as the borrow checker?

The borrow checker is a concept whose job is to enforce the borrowing rules, which can be checked at compile or runtime. Period.

[cl333r]

Yet another analogy:
you like surfing on the roof of cars, but you never had an accident, yet Rust would treat you like a looser because Rust's train of thought goes like this: Roof surfing is really dangerous, you could fall down and cause accidents, therefore you have to be treated like a noob, just in case, for security purposes, which in Rust's case means - crashing the app. And all I'm saying is that in like 99+% of the time people surfing on cars don't cause accidents, they're normal people and shouldn't be jailed "for security reasons, just in case".

Then stop breathing air, because air is dangerous it can transmit viruses, stop driving cars - they can crash, stop flying airplanes, stop eating, etc, did you get it already?

[IndioNuvemChuva]

Desired behavior for me, maybe not for you: removing items from a vector looping from end to start, removal decided based upon certain item criteria.

You... Do realize the performance of editing a vector in place that way you've described actually scales horribly with the number of items, right? Like, much, much worse than just pre-allocating and copying the items you want over to another vector; doing which also has the added bonus of not needing aliasing. :^)

[mdedetrich]

The borrow checker is a concept whose job is to enforce the borrowing rules, which can be checked at compile or runtime. Period.

No, the borrow checker is Rust's colloquial name for their linear/affine substructural type system used to check borrow semantics at compile time, see https://en.wikipedia.org/wiki/Substructural_type_system, https://doc.rust-lang.org/1.8.0/book...wing.html#meta and https://rustc-dev-guide.rust-lang.or...r-borrow-check

Never ever has Rust's lexicon (or the community in general) has called RefCell part of the borrow checker. The term borrow checker in fact comes from linguo that you can find in the Rust compiler source (since it is a compile time check).

You are confusing (and probably deliberately muddling) borrow semantics with borrow checker, they are not the same thing. Borrow semantics can be done at runtime or compile time, the borrow checker is a specific compiler type-checking phase done at compile time.

[cl333r]

You... Do realize the performance of editing a vector in place actually scales horribly with the number of items, right? Like, much, much worse than just pre-allocating and copying the items you want over to another vector; doing which also has the added bonus of not needing aliasing. :^)

You.. Do realize the point of tradeoffs?

[oleid]

You didn't understand: one single function calls borrow_mut() onto the same instance of a RefCell object, let's call this function SuckMuhBalls(), but different callers into SuckMuhBalls() might call SuckMuhBalls() while said RefCell object is already borrowed or not, depending on this SuckMuhBalls() might succeed or crash the app. Hence the problem: how do you know all possible runtime function call paths into SuckMuhBalls() to make sure it never crashes the app?

The funny thing about a RefCell is: you rarely use it at all. And in a multithreaded context, the compiler prevents its usage. If what you describe would happen in your code, then your callstack would be severely broken anyeay, as the mutable acess is released if access goes out-of-scope.

[IndioNuvemChuva]

You.. Do realize the point of tradeoffs?

You surely don't seem to. You can very much alias mutable points in Rust, for no extra cost, using unsafe code, if you're willing to trade off and yet here we are.

[oleid]

You.. Do realize the point of tradeoffs?

That, and in-place mutation of a vector is not a problem in rust.