The non-intrusive ad-hoc borrowing scheme…

[Ola Fosheim Gr]

On Friday, 22 November 2019 at 15:32:14 UTC, Nick Treleaven wrote:
> On Wednesday, 20 November 2019 at 06:40:50 UTC, Ola Fosheim 
> Grøstad wrote:
>> But maybe it could be configured in a more granular manner 
>> than on/off.
>
> Do you have any ideas on that?

There are so many options... but if set aside "debug-only 
ref-counting" then this could be an possible "performance 
philosophy":

I thought about something yesterday regarding bounds checks. I 
think it would be nice if one could state a code section should 
be @high_performance and then get warnings everywhere safety 
checks had survived all the optimization passes. Then one would 
have to mark those bounds checks as "necessary" to get suppress 
the warning. So that you basically can write safe code that is 
performant and focus time and energy where it matters.

If one had ARC optimization like Swift, then maybe something 
similar could be done for reference counting. In a 
@high_performance section one would get warnings if the refcount 
is changed and would have to do explict "borrow statements" to 
suppress the warnings. Then one could later figure out a way to 
move those out of performance sensitive code (like loops).

> One nice thing is that the struct doesn't need to expose an 
> element by ref unless the user needs to pass it as a ref 
> argument to some function.
>
> Instead, the struct can define opIndexAssign and 
> opIndexOpAssign, which don't need to bump the reference count. 
> I probably didn't get that far with my proof of concept RCSlice.

Another interesting thing about having RCSlices is that you might 
find a concurrency use case where you could put write locks on 
only certain parts of an array and have safe read/write access to 
different slices of the same array without error prone manual 
locking... not sure exactly how that would work out in terms of 
performance, but it could at least be useful in debug mode.