D language and .NET platform

[David Piepgrass]

On Sunday, 29 July 2012 at 16:32:10 UTC, Alex Rønne Petersen 
wrote:
> On 29-07-2012 17:36, bearophile wrote:
>>> .NET is too limited to represent the language,
>> Can you tell us why?
> Array slices. The .NET type system has no way to represent them 
> because it's designed for precise GC, and array slices allow 
> interior pointers in the heap (as opposed to the stack when 
> passing a field of an object by reference to a function, or 
> whatever).

D is theoretically designed for precise GC, too. But in .NET you 
can only have a reference to an array as a whole, so a slice must 
be represented as an array, offset and length. The real problem I 
see is that in D you can have a slice that does *not* refer to an 
array on the GC heap, such as a slice on a non-GC heap, or on the 
stack (currently, in fact, in D you can easily make pointers and 
slices that point to stack data to outlive the stack frame, which 
the 'safe' .NET type system inherently prevents).

.NET allows one to break the type system using pointers (in 
functions marked 'unsafe'), so as far as I can tell D for .NET 
could theoretically do everything that native D does, but with 
some annoying caveats mainly related to garbage collection. For 
instance, in a slice, I believe you can't use the same memory 
word to refer to an array on the GC heap OR an array that is not 
on the GC heap (unless you want to pin all your arrays, and you 
really don't). IIUC, doing so can crash the garbage collector.

I'm thinking that a .NET D slice would be implemented as a 
reference to a GC array and two integers (start and length). If 
the slice refers to a non-GC array, it would be stored in the 
same space, as a null reference, a pointer cast to IntPtr, and a 
length. However, this would make the code for accessing a slice 
rather clumsy and/or inefficient.

.NET has other limitations too, but again I expect there would be 
workarounds.