www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - immutability and constness

reply "Minas Mina" <minas_mina1990 hotmail.co.uk> writes:
I'm fairly new to D, but I have been using C++ for a while now 
(about 5 years, selftaught).

 From what I have learned, const in C++ is inconsistent.

For example:

int main()
{
    const int x = 0; // could be placed in ROM because it's known 
at compile time
}

void f(int x)
{
   const int y = x * x; // logical const
   // blah blah blah
}

const can be also cast away (const_cast if I remember correctly - 
I wasn't doing it often :) ) and mess everything.

 From what I understand, immutable in D is truly immutable. But I 
have seen some code here on the forum that casts aways 
immutability... (Is that even defined behaviour? What if that 
thing was in ROM?)

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.

Can someone explain what are D's goal about immutable, const - 
and why it is bitwise const and not logical? 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.

Thanks.
Jul 11 2012
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.
Jul 11 2012
next sibling parent "Chris NS" <ibisbasenji gmail.com> writes:
On Thursday, 12 July 2012 at 00:37:22 UTC, H. S. Teoh wrote:

 On Thu, Jul 12, 2012 at 02:14:30AM +0200, Minas Mina wrote:
 [...]

 ********** wall o' text **********




You forgot about their quantum uncertainty loving transvestite 
cousin: inout.
Jul 11 2012
prev sibling parent reply "Minas" <minas_mina1990 hotmail.co.uk> writes:
Thanks a lot!
So what is the problem with (logical)const? Is it needed that
much? And why some methods (toString(), toHash()) HAVE to be
const? I mean, what's the problem if they aren't?
Jul 12 2012
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 07/12/2012 07:13 AM, Minas wrote:

 Thanks a lot!
 So what is the problem with (logical)const? Is it needed that
 much? And why some methods (toString(), toHash()) HAVE to be
 const? I mean, what's the problem if they aren't?


Here is the problem:

class C
{}

// Good foo: Takes as const(C) because it is not going to
// change the object
void foo(const(C) c)
{
     c.toString();
     /*
      * With dmd 2.059:
      *
      * Error: function object.Object.toString() is not
      * callable using argument types () const
      */
}

void main()
{}

Notes:

1) The current attempt of making toString() and friends const would fix 
that problem.

2) It brings a limitation: What job does the base class have 
constraining the derived class's toString()? What if the derived really 
needed to mutate the object in toString()?

(That is why I almost never make abstract member functions 'const' in my 
C++ coding. Base can't know mutability needs of the derived.)

3) [This warrants another thread or even an article.] You may argue that 
foo() API is problematic because despite the sensible const(C), which 
nicely binds to mutable and immutable, it cannot be forwarded 
efficiently to another function that takes an immutable:

class C
{}

void foo(const(C) c)
{
     bar(c);
     /* Error: function deneme.bar (immutable(C) c) is not
      * callable using argument types (const(C))
      */
}

void bar(immutable(C) c)
{}

void main()
{}

But what if the c that foo() took was immutable to begin with? foo()'s 
const(C) parameter erases that information.

To unerase, it must be a template and its parameter must be smart to 
copy if the original object was mutable:

// Warning: Very raw idea!
void foo(T)(CopyableOrForwardableConst!C c)
{
     bar(c);    // makes an immutable copy if necessary,
     zar(c);    // or not, depending on
                // whether original object c is mutable or immutable
}

Ali

-- 
D Programming Language Tutorial: http://ddili.org/ders/d.en/index.html
Jul 12 2012
parent "Minas Mina" <minas_mina1990 hotmail.co.uk> writes:
On Thursday, 12 July 2012 at 14:42:17 UTC, Ali Çehreli wrote:

 On 07/12/2012 07:13 AM, Minas wrote:

 Thanks a lot!
 So what is the problem with (logical)const? Is it needed that
 much? And why some methods (toString(), toHash()) HAVE to be
 const? I mean, what's the problem if they aren't?


 Here is the problem:
 ....



 (That is why I almost never make abstract member functions 
 'const' in my C++ coding. Base can't know mutability needs of 
 the derived.)
 Ali


I see. Just because toString() in object is const, so must be in
the derived classes thus limiting them.

So now I understand the solution that Andrei is considering
(removing those from object). I think this is a good thing to do,
those functions don't belong there (I have had some experience
with Java's equals(Object o). All I say is that it sucks.)

In C++, I would use a templated function. If the type didn't
provide those methods it would be a compile error. Nice and clean
:)

Thanks for the reply :)
Jul 12 2012