D safety! New Feature?

[Mark Twain via Digitalmars-d]

One of the biggest problems with memory is that it's inherently 
unsafe. We know the solution to that is immutability. Immutable 
memory is inherently safe. The problem is that Immutable memory 
is useless because it cannot be changed. To make it useful and 
safe we have to cheat by creating mutable things then turning 
them in to immutable things, which is safe, but generally not the 
other way around, which is unsafe.

So, Immutable memory sort of as a direction, that if we follow 
it, we are safe, and when we go in the opposite direction, we are 
unsafe.

Now, to real world stuff. I was building some container classes 
using mixin templates like:

// An Immutable Array Template
template _ImmutableArray(T, A)
{
     // Has functionality to create itself from a indexable object 
and supply accessor methods for indexing, etc. The typical array 
stuff.

}

template _MutableArray(T,A)
{
     mixin _ImmutableArray!(T,A);

     // Adds stuff so we can mutate the array(change it's length, 
remove elements, etc...
}

struct ImmutableArray(T)
{
     mixin _ImmutableArray!(T,A);
}


struct MutableArray(T)
{
     mixin _MutableArray!(T,A)
}


With such a pattern we can build up a hierarchy of templates that 
have corresponding run-time types. We can use introspection by 
having things like IsImmutable, etc. Very oop like, but with 
static constructs. On top of these we can build stacks(just a 
MutableArray), a queue(a MutableArray with Enqueue and Dequeue), 
a circular queue(a fixed array(length can't change)), and their 
immutable variants.

Now the cool thing about this, I think, is that we can do stuff 
like:

global ImmutableArray!int Data;


MutableArray!int DataCopy = Data.Copy; // Creates a mutable copy 
of Data.
... Do work with DataCopy ...
Data.Replace(DataCopy); // Makes a copy of DataCopy.


Note that Data is immutable and doesn't even have functionality 
that mutate the Data. So we know that we never mutate Data(this 
is checked at compile time). Immutable data always has it's own 
copy. The difference is that this is a weaker form of standard 
immutability. It allows us to logically separate code that 
mutates something with the code that doesn't. We can reduce 
overhead of allocating relatively simply:

void foo()
{
     MutableArray!int Data;
     scope(Exit) Data.Reuse();
}

Reuse can simply mark the memory reusable rather then freeing it. 
This memory can then be reused the next time foo is called(or 
possibly use the stack for memory). Utilities could find optimal 
uses for typical program behavior. e.g., foo uses on average 500 
bytes for Data. Hence allocate the capacity for Data to 500 bytes.

While compiler support would make this shine, I think the main 
benefit is that one doesn't keeps mutable functionality with 
mutable data and immutable functionality with immutable data. The 
more a program works with immutable the safer it gets. It's 
leaving the little dropping of mutable data around that create 
the hard to find bugs. It makes it easier to reason about 
code(compiler or tool support can make it even better).  
Basically all the benefits of immutability as that is all it is 
but with a bit more type logic than the keyword.

e.g., If you use intelligent and mark something immutable, You'll 
still have "access" visually to all the mutable functionality. If 
you don't use intelligent, you'll get a compile time error higher 
up the stream that is more meaningful(basically trying to access 
a member that doesn't exist in the type).