Date: Sat, 11 Jan 2025 20:22:21 +0100
> On 11. Jan 2025, at 13:34, Robin Savonen Söderholm via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> Interesting idea, having a library based borrowchecker. I honestly don't think you need the "last used"-destructor, more on that later.
>
The "last used"-destructor would get used as a consteval member functions. We’d need a way to know when a borrow ends (at the earliest point possible–especially if it is a mutable borrow).
> But I am afraid that you really need some serious new meta-programming facilities to pull this off. Heap-allocations, sum-types, various branching logics... The problem with the reference counting idea is that the conditionals may be at runtime but you are asking the compiler to figure it out at compile time. You would essentially have to somehow generate the ref-counting results for each possible permutation of branch jumps and ensure correctness for each. I don't know how Rust solves it "under the hood". And then add the problem of linking translation units: somehow you must pass the correct information of lifetimes across compilation units without introducing overhead.
>
My understanding of borrow checking is that it is only done at the function scope. You can hand a borrow as parameter to a function, but you get it back when the function returns. Or you can move ownership to the function (and loose access to the variable all together). Borrows created within a branch would also end at the branch’s scope. Maybe my view of borrow checking being entirely local is too simplistic. I think you need to work around some of Rust’s borrow checker with Box (it’s kind of a unique_ptr?) and Rc/Arc (=(atomic) reference count, kind of a shared_ptr?). The only thing a little more complex is how to implement lifetime annotations in C++ (especially the syntax when it’s library-based => maybe as a template parameter).
At least my impression is that the reasoning about borrows by the programmer is local. If we need to do some final borrow checks at link time, I don’t think it can be done as a library. (Or at least shouldn’t be done as library.)
>
> Interesting idea, having a library based borrowchecker. I honestly don't think you need the "last used"-destructor, more on that later.
>
The "last used"-destructor would get used as a consteval member functions. We’d need a way to know when a borrow ends (at the earliest point possible–especially if it is a mutable borrow).
> But I am afraid that you really need some serious new meta-programming facilities to pull this off. Heap-allocations, sum-types, various branching logics... The problem with the reference counting idea is that the conditionals may be at runtime but you are asking the compiler to figure it out at compile time. You would essentially have to somehow generate the ref-counting results for each possible permutation of branch jumps and ensure correctness for each. I don't know how Rust solves it "under the hood". And then add the problem of linking translation units: somehow you must pass the correct information of lifetimes across compilation units without introducing overhead.
>
My understanding of borrow checking is that it is only done at the function scope. You can hand a borrow as parameter to a function, but you get it back when the function returns. Or you can move ownership to the function (and loose access to the variable all together). Borrows created within a branch would also end at the branch’s scope. Maybe my view of borrow checking being entirely local is too simplistic. I think you need to work around some of Rust’s borrow checker with Box (it’s kind of a unique_ptr?) and Rc/Arc (=(atomic) reference count, kind of a shared_ptr?). The only thing a little more complex is how to implement lifetime annotations in C++ (especially the syntax when it’s library-based => maybe as a template parameter).
At least my impression is that the reasoning about borrows by the programmer is local. If we need to do some final borrow checks at link time, I don’t think it can be done as a library. (Or at least shouldn’t be done as library.)
Received on 2025-01-11 19:22:25