This borrow checker runs at runtime, which I find not as interesting. Everything starts to look a lot like std::unique_ptr which I think is mostly unneeded as it ads pointer indirection.
Could someone explain to me when one would use this? Is it for educational purposes perhaps?
I don't think it is intended to be used in a real system, this was more of an experiment to see what was possible. C++ as a language isn't well-suited to supporting a compile-time borrow checker. The difficulty of retrofitting C++20 modules to the language is probably just a glimmer of the pain that would be involved in making a borrow checker work.
There is a place for runtime borrow checking. Some safe cases in well-designed code are intrinsically un-checkable at compile-time. C++ is pretty amenable to addressing these cases using the type system to dynamically guarantee that references through a unique_ptr-like object are safe at the point of dereference. Much of what the borrow checker does at compile-time could potentially be done at runtime with the caveat that it has an overhead.
This has more than a passing resemblance to how deadlock-free locking systems work. They don't actually prevent the possibility of deadlocks, as that may not be feasible, but they can detect deadlock conditions and automatically edit/repair the execution graph to eliminate the deadlock instance. If a deadlock occurs in a database and no one notices, did it really happen?
Hey, I am the author of this,
I made this mostly for the purpose of experimenting and playing around and trying out things rather than actually using this for production projects. Making a proper compile time checker is pretty complicated(possibly impossible) without actually getting into the compiler, this just intends emulate that behavior to some extent and have a similar interface.
"educational purposes" -> well kinda, I had some free time and had an interesting idea perhaps
> Could someone explain to me when one would use this? Is it for educational purposes perhaps?
The goal/why is, as almost always, explained in the README:
> rusty.hpp as the time or writing this is a very experimental thing. Its primary purpose is to experiment and test out different coding styles and exploring a different than usual C++ workspace.
jandrewrogers|1 year ago
There is a place for runtime borrow checking. Some safe cases in well-designed code are intrinsically un-checkable at compile-time. C++ is pretty amenable to addressing these cases using the type system to dynamically guarantee that references through a unique_ptr-like object are safe at the point of dereference. Much of what the borrow checker does at compile-time could potentially be done at runtime with the caveat that it has an overhead.
This has more than a passing resemblance to how deadlock-free locking systems work. They don't actually prevent the possibility of deadlocks, as that may not be feasible, but they can detect deadlock conditions and automatically edit/repair the execution graph to eliminate the deadlock instance. If a deadlock occurs in a database and no one notices, did it really happen?
jmax01|1 year ago
38|1 year ago
Rust does it at compile time, so why cant C++? to me this detail completely kills the usefulness of this project
ramon156|1 year ago
Ygg2|1 year ago
For memes, obviously.
Me: I want Rust!
Tech lead: We have Rust at home!
Rust at home: rusty.hpp
CaptainOfCoit|1 year ago
The goal/why is, as almost always, explained in the README:
> rusty.hpp as the time or writing this is a very experimental thing. Its primary purpose is to experiment and test out different coding styles and exploring a different than usual C++ workspace.
TLDR: it's a experiment
cogman10|1 year ago
Interesting, why is this? I would have assumed the compiler could have optimized away that indirection.
[1] https://godbolt.org/z/9Pqqqz5a7
steveklabnik|1 year ago
zozbot234|1 year ago
38|1 year ago