The non-intrusive ad-hoc borrowing scheme…

[Ola Fosheim Grøstad]

On Wednesday, 13 November 2019 at 20:13:47 UTC, IGotD- wrote:
> Is this something that is done during compile time or run time 
> or both?

At runtime and possibly an analysis of a log after running, in 
the general case, as that would cover much more than can be done 
by static analysis. BUT the syntax should be such that it also 
could be used as annotations for verification/static analysis.

However you might need some compile time support to make pleasant 
to use.


> 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.

Yes, that is how Swift works. However, my assumption here is that 
we don't care about execution speed, we only care about getting 
as good information as possible so the programmer can get a good 
view of the weaknesses in his program.

> 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.

A generic reference counting scheme implies shared ownership, so 
that would be slightly different from borrowing (in the sense 
that you with borrowing only "rent a view" on the object, but 
never do something drastic with it like deleting it or handing it 
to another context/thread).

The point of counting borrowing is to be able to test whether the 
program behaves according to the spec. Like, you could even 
support casting "old" objects to immutable if nobody has borrowed 
the object at that time. However, this check would not be done in 
release-mode, so problems could still occur. The quality would 
depend on how rigid the testing regime is.