Interesting idea, having a library based borrowchecker. I honestly don't
think you need the "last used"-destructor, more on that later.
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.
 You tell yourself that having a vector of borrowed (or checked) types,
meaning that we must be able to reason about the state of the heap at
compile time. I'd love to help, but not sure how much time I have. But if
you want to brainstorm, you can email me directly and I'll see how much I
can help, unless we should continue this thread. Not sure if this forum is
suitable for brainstorming ideas.

// Robin

// Robin

On Tue, Jan 7, 2025, 15:32 Henry Miller via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
>
> On Sat, Jan 4, 2025, at 09:11, Simon Schröder via Std-Proposals wrote:
> > Hi,
> >
> > Its my first time on this mailing list and I also don’t have any
> > experience with the standardization process. Any help is welcome.
>
> TLDR: if you are willing to work full time on this you can at best get it
> for C++32, but C++38 is more realistic.
>
> I was hoping someone else would reply as they know more than me. Your
> have outlined a complex and interesting idea. However ideas are the easy
> part. What is needed is someone to do the hard complex work of proving the
> idea works in the real world (we were burned by export which seemed like a
> great idea but in the real world didn't work.) For your idea you need
> working code so we can evaluate it. That means writing the library you
> want so we can see how it works, possibly modifying a compiler (clang is
> most commonly used for this) to provide a working example. Then show that
> this library can be used in the real world - take some multi-million line
> codebase and show how you can add borrow checking to a small part without
> cascading errors until you everyone gives up. (const correct used to be a
> big deal - it took decades to get older cost bases const correct, if we are
> a looking at the same decades until this is adoptable in the real world we
> at least need to know going in - this may or may not itself be enough to
> say no we won't standardize this)
>
> We cannot get your std::borrow into c++29, while the papers are easy
> enough to write, they point to a larger feature and you will need to show
> that the entire feature actually will come in the future and also that
> those things are useful stand alone. And the existence of the std2 means
> we need a debate about which way forward to go. That debate will take some
> time - often when one side brings up an objection the other will go "just
> give me some time" and a couple months later they will have solved (or
> mitigated) that objection. My quick read is the std2 the better way, and
> thus what I would want if this was 1980 (that is well before the current
> STL), but given all the millions of lines of C++ that use the STL today I'm
> worried that nobody could adopt it in any existing code base (again, a
> quick read so I reserve the right to change my mind).
>
> I don't want to discourage you. C++ needs to do better. and your ideas
> are on a good track. However getting anything needs smart people to put in
> a lot of effort. Profiles seem to me something we can get for C++29, but
> they also appear limited. Various forms of borrow checking look like they
> might be a much better option, but they also need a lot more effort to get
> in (if they go in - I reserve the right say no based on something unknown
> today). At this point I want to encourage everyone with an idea to
> implement and present it so we can try it with real world code to see if it
> can be used.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>