mutable, const, immutable guidelines

[qznc]

On Wednesday, 9 October 2013 at 04:41:35 UTC, Ali Çehreli wrote:
> > 4. Data structures should not restrict themselves to be
> mutable, const,
> > or immutable.
>
> What is the template of a struct that can be used as such? 
> Providing simple values seems to be insufficient:
>
> struct MyInt
> {
>     int i;
>     private int[] history;
> }
>
> What else should the struct above have to make it usable as 
> mutable, const, immutable?
>
> > This is a noble goal, which in reality is probably either
> trivial or
> > impossible. So I am not sure, if it is worthy to be called a
> guideline.
>
> We have to nail this down already. We have this great addition 
> of immutable in the language but we either don't know how to 
> use it or the language is lacking hopefully trivial things to 
> make it work.

For this case, there are basically two approaches: a) prevent the 
use as immutable in the first place or b) make it work as 
immutable by force.

For version a) we could have a UDA like this:

   @NeverImmutable struct MyInt { int i; }

   auto x = immutable(MyInt)(42);  // compile error
   immutable y = MyInt(42);        // compile error

However, the library writer would have to anticipate the private 
dynamic array, which probably does not happen. Defensive coding 
like putting @NeverImmutable on everything would defeat the 
purpose as well.

For version b) we would relax the type system, which opens an 
ugly can of worms of unknown size. Basically, immutable data 
would be allowed to have mutable private data, if the author 
sufficiently asserts everything is correct. Since there are lots 
of interesting compiler optimizations with immutable things, I 
can imagine there will be lots of subtle errors until one can 
make something like this work.

At this point, I cannot imagine that there is a solution which 
makes this case work, so I think we have to accept this breakage.