Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
@aggelalex Some functions can't be split very well because there's a lot of shared data or because there are procedurally enforced invariants which can't be easily visually verified unless all points of interest are colocated.
Also, this can be said about everything from static typing to memory management. Rust's main innovation is precisely that almost everything is explicit but verified, so your code doesn't have to be pristine in order to be able to assert invariants. -
@aggelalex All I'm suggesting is to add "this code doesn't destroy any objects of this type" to the set of possible assertions Rust helps verify.
I finally got it working! Now I have a foundation for a kernel and an uefi bootloader written in pure Rust
To...
Hot take: Rust doesn't go far enough with explicit clone; dropping any type that isn't trivially copiable should also be explicit. I don't mean that it should be leaked if you don't delete it, I mean that the compiler should force you to explicitly say
"I am done with this object, anything that had to know about it has already been notified and either there isn't a single last point of use or it isn't a clone, therefore dropping is justified."
This is the whole meaning of dropping a complex object. I think that this is far too strong a statement to imply in bulk for every value in scope at the end of the function.
rant
rust
langdev
explicit code