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?
> Everything starts to look a lot like std::unique_ptr which I think is mostly unneeded as it ads pointer indirection. Interesting, why is this? I would have assumed the compiler could have optimized away that indirection. [1] https://godbolt.org/z/9Pqqqz5a7
Rusty.hpp: A Borrow Checker and Memory Ownership System for C++20
161–170 of 174 posts
Re: Rusty.hpp: A Borrow Checker and Memory Ownership System for C++20
#162Earlier quoted context omitted.
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…
> pretty complicated(possibly impossible) Rust does it at compile time, so why cant C++? to me this detail completely kills the usefulness of this project
> pretty complicated(possibly impossible) without actually getting into the compiler
Re: Rusty.hpp: A Borrow Checker and Memory Ownership System for C++20
#163What's the point of adding Option , Result and Rc/Arc when std::optional, std::expected and std::shared_ptr exist?
std::optional is a poor shadow of Option. It's what happens when C++ programmers who've seen a Maybe type in a window (years ago by the way, this isn't inspired by Rust, it was just stuck in the standardization process until C++ 17) but are starved of proper types and basic features like pattern matching try to imitate what they saw. As a result for example std::optional doesn't exist, because to a C++ programmer it…
[deleted]
Re: Rusty.hpp: A Borrow Checker and Memory Ownership System for C++20
#164Earlier quoted context omitted.
Interesting - so essentially calling a "non-const" (mutable) method invalidates any existing references to the object, with this being implemented at compile time by not allowing the mutable method to be called while other references are still alive ? How exactly is this defined for something like index() which is returning a reference to a different type than the object itself, and where the declaration doesn't indi…
> Interesting - so essentially calling a "non-const" (mutable) method invalidates any existing references to the object, with this being implemented at compile time by not allowing the mutable method to be called while other references are still alive ? Yes, exactly. > How exactly is this defined for something like index() which is returning a reference to a different type than the object itself, and where the declar…
Thanks!
Re: Rusty.hpp: A Borrow Checker and Memory Ownership System for C++20
#165What's the point of adding Option , Result and Rc/Arc when std::optional, std::expected and std::shared_ptr exist?
std::optional is a poor shadow of Option. It's what happens when C++ programmers who've seen a Maybe type in a window (years ago by the way, this isn't inspired by Rust, it was just stuck in the standardization process until C++ 17) but are starved of proper types and basic features like pattern matching try to imitate what they saw. As a result for example std::optional doesn't exist, because to a C++ programmer it…
Easy. When you want std::optional just use T*.
Re: Rusty.hpp: A Borrow Checker and Memory Ownership System for C++20
#166 auto foo2 = foo0; // foo0's ownership is not transfered to foo2
Re: Rusty.hpp: A Borrow Checker and Memory Ownership System for C++20
#167Earlier quoted context omitted.
Rust has unique and shared pointers too (Box and Arc/Rc). But using them when unnecessary results in extra heap allocations. I’m not aware of C++ compiler that can consistently rewrite uses of unique_ptr to heap-allocated objects to use raw pointers to stack-allocated objects instead.
I didn't mean trying to rewrite code to change dynamically allocated objects to stack based ones. That sounds more like an optimization that a managed language like C# might do. C++'s unique_ptr and shared_ptr both have a get() method that will return you a raw pointer to the managed object, which can be a safe optimization within a function holding ownership to the object, as well as allowing you to use legacy funct…
As these are templates, processed statically, isn't this essentially happening already?
Re: Rusty.hpp: A Borrow Checker and Memory Ownership System for C++20
#168Earlier quoted context omitted.
I actually don't care that much about the monadic functions. For me the important use case is pattern matching, which C++ doesn't yet have. Pattern matching really changes how you see the entire language.
C++ has pattern matching through overloading.
How do you figure?
Re: Rusty.hpp: A Borrow Checker and Memory Ownership System for C++20
#169Earlier quoted context omitted.
> Where Rust won't compile when a lifetime can't be determined, IIRC Nim's static analysis will make a copy (and tell you), so it's more as a performance optimisation than for correctness. Wait, how does that work? For example, take the following Rust function with insufficient lifetime specifiers: pub fn lt(x: &i32, y: &i32) -> &i32 { if x You're saying Nim will change one/all of those references to copies and will…
It will not emit warnings saying it did that. The static analysis is not very transparent. (If you can get the right incantation of flags working to do so and it works, let me know! The last time I did that it was quite bugged.) Writing an equivalent program is a bit weird because: 1) Nim does not distinguish between owned and borrowed types in the parameters (except wrt. lent which is bugged and only for optimizatio…
Oh, that's interesting. I think not distinguishing between owned and borrowed types clears things up for me; it makes a lot more sense for copying to be an optimization here if reference-ness is not (directly?) exposed to the programmer.
Thanks for the explanation and the reading suggestions! I'll see about taking a look.
Re: Rusty.hpp: A Borrow Checker and Memory Ownership System for C++20
#170auto foo2 = foo0; // foo0's ownership is not transfered to foo2 was this supposed to say "now transferred"?
Yes thats a typo