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

[Gregor Mückl]

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.

Pointers allocated through malloc() or acquired from external 
code would carry the information that they are non GC-memory as 
part of their type. Let's just designate that with a @native 
attribute for now.

This attribute limits what you can do safely:

- No overwriting a @native pointer address with the result of 
pointer arithmetic. Don't overwrite the pointer that needs to be 
free'd.
- Casting pointers to different types (e.g. to array types) 
transfers the @native-ness of the input pointer
- No assignment between @native and non- at native pointer-like 
types. Casting to or from @native is a @system operation.
- ~ and ~= for @native arrays always produce a copy on the GC 
heap and the result is therefore not @native. No in-place 
appending. All other implicit language-level copy operations 
perform similar conversions.
- pointers returned from extern(C)/extern(C++) functions are 
always @native (if that is not the case, then an unsafe wrapper 
must be written)

Unresolved:
- @native-ness could probably be inferred by static analysis 
within a single non-template function. It would have to be 
declared at function interfaces. This grows the attribute zoo.
- Some function can only work on @native pointers, others only on 
non- at native ones, a third kind can work with both.
- Pointer arithmetic on @native pointers would need some serious 
lifetime analysis to make that safer.
- No claim of completeness or soundness of these rules is made at 
this time :)