Logical Const using a Mutable template

[Jesse Phillips]

Max Samukha Wrote:

> On 11/30/2010 09:30 AM, Jesse Phillips wrote:
> > This came up in discussion and I think the behavior is safe and usable when wanting to change class data in a const function.
> >
> > http://article.gmane.org/gmane.comp.lang.d.general/43476
> >
> > One limitation is that value types declared as Mutable (Mutable!(int)) can not be changed if the encapsulating class is declared immutable. For this reason a Mutable value can not be changed inside a const function. I think this is acceptable.
> >
> > Another limitation appears to be an issue with alias this. It is commented as a //FIXME in the code.
> >
> > https://gist.github.com/721066
> 
> It is not enough to forward opAssign and opEquals. Any operator should 
> be handled. For example, change the implementation of A.foo to
> 
> n2 += 1;
> 
> and you will get a segfault during compilation.
> 
> You could add more kludge with operator overloads but I don't think it 
> is worth the effort. It makes more sense to wait until "alias this" bugs 
> are fixed. On the other hand, we may wait forever since the way "alias 
> this" should handle operators has never been specified.
> 

The intent isn't to work around alias this bugs. It is to provide mutation in a const function, but with the guarantee that it will not result in undefined behavior. (I should have stated that first, but it was getting late). Concurrency shouldn't be any different from having a reference in a class you are sharing. Sharing immutable objects should be fine as they still can not have their state changed.

The rules for this are:

* Only mutable data can be assigned to a Mutable
* Modification of referenced fields can be modified (inner class fields, pointer targets)

I'll be back to finish this in a bit.