Another Transitive const solution

[Alex Burton]

I wonder how many lurkers like me are waiting for D 2.0s const system to be sorted out so that we can start using it.
Experience shows that const is viral and you are either using it or not using it, and if libraries are using it, then you have to use it or you can't use the libraries.
So I am not going to write a bunch of D 1.0 code until D 2.0's transitive const is fixed.

Goals of transitive const
1. To make the compiler able to perform optimisations based on const.
2. To make a documenting const system that is checked by the compiler and useful to the programmer.

Goal 1 is not achievable as has been shown previously in this group :

interface A
{
	const int getInt();
};

class B
{
	const int getInt()
	{
		int x;
		readfln("%d",x);		//any c function in a library that might use statics - fread() etc.
		return x;
	}
};

int main()
{
	const A a = new B;
	
	int answer = a.getInt()*10 - a.getInt()*100;
}

The side effects of, and the results of a const member function are not garanteed to be the same.
No optimisations that change calling order can be done.
No optimisations that remove redundant calls can be done.
What other optimisations does transitive const allow ?

I think that transitive const is still useless to the compiler for optimisation purposes, and that has to be left for the pure specifier.

Transitive const could still be useful for goal 2 like this :

class A
{
	int value;
	void set(int x)
	{
		value = x;
	}
	const int get()
	{
		return value;
	}
};

class B
{
	part A a1;
	A a2;
	const int get()
	{
		a1.set(7);		//compilation error - can't modify a1 in const member function because it is part of B 
		a2.set(5);		//ok a2 can be modified as it is not part of B it is just an object that we are looking at.
		return a1.get()*a2.get();
	}
};

So introduce a new keyword : "part" or similar and then we have a powerful const system for goal 2.
And leave goal 1 for the pure specifier and future developments.

Alex