IDEA: invariant-related gc hints

[Jarrett Billingsley]

"bearophile" <bearophileHUGS at lycos.com> wrote in message 
news:g6b4h3$1748$1 at digitalmars.com...

> So can't a way be invented to tell the D compiler that some parts of D 
> code are restricted in Java-like capabilities (no C-style pointer 
> management), so the GC can work on them (if they contain OOP) at that 
> higher level with hopefully higher performance on very-OOP code (this may 
> requires a quite more complex GC)? I don't know if this can be done, 
> because you can't make such parts of code transitively safe. This is 
> another possible advantage of the "safe D" Walter was talking about.

Hmmmm.  If only....... oh!  wait, that's right.

http://www.digitalmars.com/d/2.0/safed.html

"When you enter SafeD, you leave your pointers, unchecked casts and unions 
at the door. Memory management is provided to you courtesy of Garbage 
Collection. Class objects are passed around using opaque handles. Arrays and 
strings are bound-checked (it's possible to turn the checks off with a 
compiler switch, but then you're no longer in SafeD). You may still write 
code that will throw a runtime exception (e.g., array out-of-bounds error, 
or uninitialized-class-object error), but you won't be able to overwrite 
memory that hasn't been allocated to you or that has already been recycled."

The only issue then is slicing.  Slicing still allows you to point into the 
middle of memory blocks, which slows down the GC.  Unless, of course, a 
slice were to have three pointers -- one to the beginning of the memory 
block, one to the beginning of the slice, and one to the end of the slice. 
Ahhh, now it's all making sense why W wants to separate slices from normal 
arrays ;)