GC/non-GC memory as part of data type?

[Gregor Mückl]

On Thursday, 14 November 2019 at 20:06:53 UTC, jmh530 wrote:
> On Wednesday, 13 November 2019 at 15:19:38 UTC, Gregor Mückl 
> wrote:
>> Hi!
>>
>> This is an attempt to follow up on the DIP1025 discussion: 
>> what happens if all pointers/arrays/references carry the 
>> origin of the pointed to memory region as part of their type? 
>> The goal is to have a cleaner, more explicit separation of GC 
>> and non-GC heaps.
>> [snip]
>
> I'm sure there's a lot that I haven't considered, but it seems 
> like that should be possible just that you might have to write 
> up some of your own functionality. You could do something like 
> below and then write some different versions of malloc, etc, 
> and GC allocation functions and anything that uses the GC (like 
> dynamic arrays), and probably your own ref too.
>
> import std.traits : isPointer;
>
> enum AllocStrategy
> {
>     GC,
>     malloc,
>     other
> }
>
> struct Ptr(T, AllocStrategy allocStrategy)
>     if (isPointer!T)
> {
>     T x;
>     alias x this;
> }
>
> void main() {
>     int x = 1;
>     auto y = Ptr!(int*, AllocStrategy.GC)(new int(x));
>     assert(*y == 1);
> }

Pushing the problem into a library type doesn't really solve 
anything. Any interesting library that you might want to use will 
not use these wrappers. If you unwrap the pointers (or worse - 
your slices) and pass them in, you lose all information about the 
guarantees that should be tracked. Remember that you don't have 
control over how that external library reallocates memory for 
data that you pass in, e.g. when it appends to a slice.