5 ms·

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 i

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?

Ygg2 2y ago
> Could someone explain to me when one would use this? For memes, obviously. Me: I want Rust! Tech lead: We have Rust at home! Rust at home: rusty.hpp
ramon156 2y ago
I think it's more an "can i do this" project, rather than a product that can be used in prod
CaptainOfCoit 2y ago
> 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. TLDR: it's a experiment
zozbot234 2y ago
Rust does "borrow checking at runtime" with RefCell<>.
- 38 2y ago
  right, but RefCell is optional. if you dont use that, you get checking at compile time.
jmax01 2y ago
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
- 38 2y ago
  > 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
  - steveklabnik 2y ago
    C++ cannot because it does not have the necessary information present in its syntax. It’s really that simple. C++ could add such syntax, but outside of what Circle is doing, I’m not aware of any real proposal to add it. Also, Google (more specifically, the Chrome folks) tried to make it work via templates, but found that it was not possible. There’s a limit to template magic, even.
    - arc619 2y ago
      Although it's not as extensive as Rust's lifetime management, Nim manages to infer lifetimes without specific syntax, so is it really a syntax issue? As you say, though, C++ template magic definitely has its limits.
      - steveklabnik 2y ago
        Nim has a garbage collector. That said, you're right on some level that it's truly semantics that matter, not syntax, but you need syntax to control the semantics.
        arc619 2y ago
        Nim is stack allocated unless you specifically mark a type as a reference, and "does not use classical GC algorithms anymore but is based on destructors and move semantics": https://nim-lang.org/docs/destructors.html https://nim-lang.org/docs/destructors.html 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. Regardless of the details and extent of the borrow checking, however, it shows that it's possible in principle to infer lifetimes without explicit annotation. So, perhaps C++ could support it. As you say, it's the semantics of the syntax that matter. I'm not familiar with C++'s compiler internals though so it could be impractical.
jandrewrogers 2y ago
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?
cogman10 2y ago
> 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 https://godbolt.org/z/9Pqqqz5a7
- steveklabnik 2y ago
  https://stackoverflow.com/questions/58339165/why-can-a-t-be-passed-in-register-but-a-unique-ptrt-cannot https://stackoverflow.com/questions/58339165/why-can-a-t-be-...

Ygg2 2y ago

> Could someone explain to me when one would use this? For memes, obviously. Me: I want Rust! Tech lead: We have Rust at home! Rust at home: rusty.hpp

ramon156 2y ago

I think it's more an "can i do this" project, rather than a product that can be used in prod

CaptainOfCoit 2y ago

> 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. TLDR: it's a experiment

zozbot234 2y ago

Rust does "borrow checking at runtime" with RefCell<>.

38 2y ago
right, but RefCell is optional. if you dont use that, you get checking at compile time.

jmax01 2y ago

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

38 2y ago
> 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
- steveklabnik 2y ago
  C++ cannot because it does not have the necessary information present in its syntax. It’s really that simple. C++ could add such syntax, but outside of what Circle is doing, I’m not aware of any real proposal to add it. Also, Google (more specifically, the Chrome folks) tried to make it work via templates, but found that it was not possible. There’s a limit to template magic, even.
  - arc619 2y ago
    Although it's not as extensive as Rust's lifetime management, Nim manages to infer lifetimes without specific syntax, so is it really a syntax issue? As you say, though, C++ template magic definitely has its limits.
    - steveklabnik 2y ago
      Nim has a garbage collector. That said, you're right on some level that it's truly semantics that matter, not syntax, but you need syntax to control the semantics.
      - arc619 2y ago
        Nim is stack allocated unless you specifically mark a type as a reference, and "does not use classical GC algorithms anymore but is based on destructors and move semantics": https://nim-lang.org/docs/destructors.html https://nim-lang.org/docs/destructors.html 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. Regardless of the details and extent of the borrow checking, however, it shows that it's possible in principle to infer lifetimes without explicit annotation. So, perhaps C++ could support it. As you say, it's the semantics of the syntax that matter. I'm not familiar with C++'s compiler internals though so it could be impractical.

jandrewrogers 2y ago

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?

cogman10 2y ago

> 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 https://godbolt.org/z/9Pqqqz5a7

steveklabnik 2y ago
https://stackoverflow.com/questions/58339165/why-can-a-t-be-passed-in-register-but-a-unique-ptrt-cannot https://stackoverflow.com/questions/58339165/why-can-a-t-be-...