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.
