Tsoding streamed about D

[Mike Shah]

On Saturday, 29 March 2025 at 11:50:58 UTC, Richard (Rikki) 
Andrew Cattermole wrote:
> On 29/03/2025 4:27 PM, Walter Bright wrote:
>> On 3/25/2025 4:19 AM, Mike Shah wrote:
>>> Indeed, I wrote my own 'DynArray' type for use in betterC. 
>>> Declaration is with 'DynArray!int intArray' for example. I 
>>> then used overloads for opSlice and such to get pretty much 
>>> the same functionality (e g. auto slice = intArray[2..4]). I 
>>> can also wrap that with a reference counted type to help 
>>> avoid leaks if lifetime and scope varies :)
>> 
>> Several of us studied reference counting for a while, and came 
>> to the unfortunate conclusion that is wasn't practical to make 
>> it memory safe without a GC or a borrow checker. Ref counting 
>> also has performance issues.
>> 
>> (Holding a non-refcounted reference to the payload of a 
>> refcounted object runs the risk of becoming a dangling 
>> pointer, but if that is disallowed, performance problems 
>> ensue.)
>> 
>> I use allocated slices all the time that don't use the GC, but 
>> I take care to manage the memory manually.
>
> There is only two solutions that I've come up with that solves 
> this:
>
> 1. Have a proper DFA solution to escape analysis
> 2. Disable any action that can lead to borrowing
>
> For system handles both work fine, and the second is needed for 
> the first anyway.
>
> And as Walter knows, I've been hammering on the DFA language 
> features stuff for a while pretty heavily. I'm waiting on an 
> update to see what I need to do next for him.

Indeed an escape analysis or borrow checker is the way to go, or 
otherwise manually managing the memory when it comes to 
performance.

I also have run into problems with ref counting (in C++ for 
example with std::shared_ptr) in regards to the control block 
that stores the ref count that needs to be atomically incremented 
when used with a multithreaded program.