immutability and constness

[H. S. Teoh]

On Thu, Jul 12, 2012 at 02:14:30AM +0200, Minas Mina wrote:
[...]
> D has const as well... This is were it becomes a bit tricky for me.
> To be honest, I haven't got the book about D - it should(does it?)
> have information about that.

You should get the book, it explains all the basic concepts (and some
advanced ones too).

Basically the way it works is like this: mutable (unqualified) and
immutable can both implicitly convert to const. So it's sorta like the
hierarchy:

	     const
	    /     \
	mutable  immutable

It's OK to convert immutable to const because const promises never to
touch the data. It's also OK to convert mutable to const, because, well,
not changing mutable data is OK too.

In some cases, you can convert immutable to mutable (if the object has
value semantics transitively to all its subparts), but as a rule, you
can't. Immutable is bit-wise unchangeable, no matter what.


> Can someone explain what are D's goal about immutable, const - and why
> it is bitwise const and not logical?

Mainly because logical const is not enforceable. Logical const means the
object does not _visibly_ change, but some hidden internal state may be
changing wildly. Visible, of course, w.r.t. to non-private code that
uses the object. But what constitutes a visible change? For example, if
I have a class:

	class C {
		int x, y;
		int getX() { return x; }
		void doStuff() {
			if (y++ > 100000) x++;
		}
	}

For the first 99999 times you call doStuff, no visible change is made,
but the next time you call it, a visible change happens. So it is not
logically const. But how would the compiler be able to tell? There could
be very complex code inside doStuff(), and the compiler would
essentially have to solve the halting problem (an unsolvable problem) in
order to know whether doStuff() is logically const.

So the only way logical const can work is to make it const "by
convention", that is, you write void doStuff() const{}, but it's up to
you the programmer to ensure that it's actually const, since the
compiler has no way to verify it. This is bad, because programmers are
human, and humans make mistakes. So the const qualifier becomes useless,
it's just an annotation, with no real guarantees.

The only way to make const enforceable is to make it bitwise const.


> How does it benefit programs? I have read something about that in the
> "general discussions" forum but posted the question here because it's
> for me (and others) to learn about that.
[...]

Immutable is a strong guarantee the data will never, ever change. So
it's safe to perform a whole range of optimizations, like allowing
multiple threads to read the data without any locks (since it doesn't
change, there is no chance of race conditions), common subexpression
elimination (reading the data multiple times across function calls is
the same as reading it once: the function call cannot change the data
because it's immutable). The compiler can put this data in ROM, where
the data physically can't change -- and will be able to verify there is
no attempt to change the data in the code.

The problem is, immutable is very restrictive, and hard to work with
(you can't change anything, you have to make a copy and change that).
So if you have some immutable data and some mutable data, you can't use
the same code to read them (because you can't convert between them).

So a common ground is introduced: const. Const means whoever has the
const object can't change anything, but somebody somewhere else may
change it. So mutable can convert to const, obviously, but so can
immutable (since in the case of immutable, _nobody_ can change it, so
the fact that the current code that handles the const data won't change
it either means that the data remains immutable). The advantage of this
is that now you can have the same code process both mutable and
immutable data. It's OK since you only ever read the data.


T

-- 
Spaghetti code may be tangly, but lasagna code is just cheesy.