The non-intrusive ad-hoc borrowing scheme…
IGotD-
nise at nise.com
Wed Nov 13 20:13:47 UTC 2019
On Wednesday, 13 November 2019 at 12:22:12 UTC, Ola Fosheim
Grøstad wrote:
> Since Rust style borrowing checks lead to various
> complications, why not embrace testing as an alternative
> approach. Basically providing something like valgrind for
> borrowing.
>
> You can track shared ownership by letting pointers and slices
> use ref-counting. That is well-known.
>
> In my own attempts to model borrowing in D, I did a tiny little
> twist to it, creating borrowing pointers that will not free
> when the refcount goes to zero. Instead they fail. So you have
> to release the owner explicitly and that can only be done when
> the refcount is zero.
>
> That allows you to track borrowing during debugging/testing,
> and turn it off in release mode. You also avoid the
> inconveniences that Rust comes with.
>
> The downside is that the resulting code is only as safe as the
> testing environment ensures…
>
> Anyway, this is relatively easy to implement if the code base
> is wellbehaved.
Is this something that is done during compile time or run time or
both?
I was thinking if you could track reference counting as far as
you can with CTFE (or any other static analysis) you could
actually remove increase/decrease of reference counting in the
code if you could prove it is safe to remove them and optimize
the code that way. When the compiler cannot statically track the
life time it inserts the associated reference counting code.
Another question is, isn't a borrow just an increase of the
reference counter? As long as someone is using the object, it
should have an associated acquired reference.
More information about the Digitalmars-d
mailing list