www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Another Transitive const solution

reply Alex Burton <alexibu mac.com> writes:
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
Apr 09 2008
next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 09/04/2008, Alex Burton <alexibu mac.com> wrote:
 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.

Just curious, but what exactly are you waiting for? Are you waiting for D2 to become stable (i.e. when D3 springs into existence)?
  I think that transitive const is still useless to the compiler for
optimisation purposes, and that has to be left for the pure specifier.

It's a simple chain of logic: pure functions require transitive invariant; transitive invariant requires transitive const.
Apr 09 2008
prev sibling next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Alex Burton" <alexibu mac.com> wrote in message 
news:fti5dd$8h7$1 digitalmars.com...
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.

What? What does constness in D2 have anything to do with D1?
Apr 09 2008
parent reply Alex Burton <alexibu mac.com> writes:
Jarrett Billingsley Wrote:

 "Alex Burton" <alexibu mac.com> wrote in message 
 news:fti5dd$8h7$1 digitalmars.com...
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.

What? What does constness in D2 have anything to do with D1?

Apr 09 2008
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Alex Burton" <alexibu mac.com> wrote in message 
news:ftjfrg$24lu$1 digitalmars.com...
 Jarrett Billingsley Wrote:

 "Alex Burton" <alexibu mac.com> wrote in message
 news:fti5dd$8h7$1 digitalmars.com...
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.

What? What does constness in D2 have anything to do with D1?

version makes me hesitant to start writing lots of code in D1.

The entire reason for making D1 _D1_ was so that people _would_ start using it. It strikes me as very odd that the exact opposite seems to have happened. You're not the only one to come to this decision. Personally I won't even consider D2 until it's frozen. Furthermore just because you write code in D1 doesn't mean you'll _have_ to start using D2.
Apr 09 2008
parent reply "Hans W. Uhlig" <huhlig clickconsulting.com> writes:
Jarrett Billingsley wrote:
 "Alex Burton" <alexibu mac.com> wrote in message 
 news:ftjfrg$24lu$1 digitalmars.com...
 Jarrett Billingsley Wrote:

 "Alex Burton" <alexibu mac.com> wrote in message
 news:fti5dd$8h7$1 digitalmars.com...
 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.


version makes me hesitant to start writing lots of code in D1.

The entire reason for making D1 _D1_ was so that people _would_ start using it. It strikes me as very odd that the exact opposite seems to have happened. You're not the only one to come to this decision. Personally I won't even consider D2 until it's frozen. Furthermore just because you write code in D1 doesn't mean you'll _have_ to start using D2.

I think this idea comes out of the same mindset as Java. You don't want to use something you know is going to be deprecated so soon down the road. Since D2.0 is an evolution of the product rather then a new language it is seen as the next version, why write something that wont work with the next version when you can write it for that version. I think its simply the fact that D2 isn't backwards compatible for a good chunk of things. Porting might end up being a bigger pain then simply waiting is. I look forward to a lot of the changes in parallel processing and library support coming for D2 and am waiting to start a few projects until D2.0s feature set is frozen, till then I merely putter.
Apr 10 2008
parent reply Georg Wrede <georg nospam.org> writes:
Hans W. Uhlig wrote:
 Jarrett Billingsley wrote:
 
 "Alex Burton" <alexibu mac.com> wrote in message 
 news:ftjfrg$24lu$1 digitalmars.com...

 Jarrett Billingsley Wrote:

 "Alex Burton" <alexibu mac.com> wrote in message
 news:fti5dd$8h7$1 digitalmars.com...

 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.

What? What does constness in D2 have anything to do with D1?

next version makes me hesitant to start writing lots of code in D1.

The entire reason for making D1 _D1_ was so that people _would_ start using it. It strikes me as very odd that the exact opposite seems to have happened. You're not the only one to come to this decision. Personally I won't even consider D2 until it's frozen. Furthermore just because you write code in D1 doesn't mean you'll _have_ to start using D2.

I think this idea comes out of the same mindset as Java. You don't want to use something you know is going to be deprecated so soon down the road. Since D2.0 is an evolution of the product rather then a new language it is seen as the next version, why write something that wont work with the next version when you can write it for that version. I think its simply the fact that D2 isn't backwards compatible for a good chunk of things. Porting might end up being a bigger pain then simply waiting is. I look forward to a lot of the changes in parallel processing and library support coming for D2 and am waiting to start a few projects until D2.0s feature set is frozen, till then I merely putter.

But nobody knows when that'll happen! It might be months, but it might as well be late /next/ year. And if you do regular (as in just normal) programmin in D1, chances that you'd have to work hard to later port it to D2 are small. Most of the things in D1 aren't going to change anyway. There'll mostly be just more things to the language. Of course, some people don't buy a new cellular phone because next year you get a twice cooler one for half the price. Or they don't buy a new computer "because they're getting cheaper and stronger all the time, so for every month I push back buying one, I actually earn money". You might as well skip waiting alltogether, because (as with any programming language) the day /will/ come when D is obsolete. But then you shouldn't marry either, because one day she'll either divorce you or die. In reality, you might get a lot of things done in D1 while waiting, and possibly even enjoy both the programming, and the results of it.
Apr 10 2008
next sibling parent Alex Burton <alexibu mac.com> writes:
Georg Wrede Wrote:

 Hans W. Uhlig wrote:
 Jarrett Billingsley wrote:
 
 "Alex Burton" <alexibu mac.com> wrote in message 
 news:ftjfrg$24lu$1 digitalmars.com...

 Jarrett Billingsley Wrote:

 "Alex Burton" <alexibu mac.com> wrote in message
 news:fti5dd$8h7$1 digitalmars.com...

 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.

What? What does constness in D2 have anything to do with D1?

next version makes me hesitant to start writing lots of code in D1.

The entire reason for making D1 _D1_ was so that people _would_ start using it. It strikes me as very odd that the exact opposite seems to have happened. You're not the only one to come to this decision. Personally I won't even consider D2 until it's frozen. Furthermore just because you write code in D1 doesn't mean you'll _have_ to start using D2.

I think this idea comes out of the same mindset as Java. You don't want to use something you know is going to be deprecated so soon down the road. Since D2.0 is an evolution of the product rather then a new language it is seen as the next version, why write something that wont work with the next version when you can write it for that version. I think its simply the fact that D2 isn't backwards compatible for a good chunk of things. Porting might end up being a bigger pain then simply waiting is. I look forward to a lot of the changes in parallel processing and library support coming for D2 and am waiting to start a few projects until D2.0s feature set is frozen, till then I merely putter.

But nobody knows when that'll happen! It might be months, but it might as well be late /next/ year. And if you do regular (as in just normal) programmin in D1, chances that you'd have to work hard to later port it to D2 are small. Most of the things in D1 aren't going to change anyway. There'll mostly be just more things to the language. Of course, some people don't buy a new cellular phone because next year you get a twice cooler one for half the price. Or they don't buy a new computer "because they're getting cheaper and stronger all the time, so for every month I push back buying one, I actually earn money". You might as well skip waiting alltogether, because (as with any programming language) the day /will/ come when D is obsolete. But then you shouldn't marry either, because one day she'll either divorce you or die. In reality, you might get a lot of things done in D1 while waiting, and possibly even enjoy both the programming, and the results of it.

I know what you mean - you can't put off buying a computer till the next version comes out because there will always be a better one coming out. But this is different, I think that the const system in D will either make it or break it. Make it as in confirm it as a complete mature, state of the art language that is a serious option, or break it as in the D community fragments into those unwilling to use the const system and stay on D 1 and those who are happy with the const system. I am itching to start working in D instead of C++ (because of the hundreds of reasons that D is better than C++), but I want to reduce the risk that I migrate into a language that doesn't have a future. For me the successful implementation of const is when I think D will have no further problems. At the moment I am just lurking on this list and occasionally trying to suggest reasonable alternatives to the current transitive const system which I think is unworkable and not of any benefit. I actually use transitive const in C++ (implemented using smart pointers) but it is an opt in system, so that I can document and have the compiler check constness. Alex
Apr 11 2008
prev sibling parent reply "Hans W. Uhlig" <huhlig clickconsulting.com> writes:
Georg Wrede wrote:
 Hans W. Uhlig wrote:
 Jarrett Billingsley wrote:

 "Alex Burton" <alexibu mac.com> wrote in message 
 news:ftjfrg$24lu$1 digitalmars.com...

 Jarrett Billingsley Wrote:

 "Alex Burton" <alexibu mac.com> wrote in message
 news:fti5dd$8h7$1 digitalmars.com...

 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.

What? What does constness in D2 have anything to do with D1?

next version makes me hesitant to start writing lots of code in D1.

The entire reason for making D1 _D1_ was so that people _would_ start using it. It strikes me as very odd that the exact opposite seems to have happened. You're not the only one to come to this decision. Personally I won't even consider D2 until it's frozen. Furthermore just because you write code in D1 doesn't mean you'll _have_ to start using D2.

I think this idea comes out of the same mindset as Java. You don't want to use something you know is going to be deprecated so soon down the road. Since D2.0 is an evolution of the product rather then a new language it is seen as the next version, why write something that wont work with the next version when you can write it for that version. I think its simply the fact that D2 isn't backwards compatible for a good chunk of things. Porting might end up being a bigger pain then simply waiting is. I look forward to a lot of the changes in parallel processing and library support coming for D2 and am waiting to start a few projects until D2.0s feature set is frozen, till then I merely putter.

But nobody knows when that'll happen! It might be months, but it might as well be late /next/ year. And if you do regular (as in just normal) programmin in D1, chances that you'd have to work hard to later port it to D2 are small. Most of the things in D1 aren't going to change anyway. There'll mostly be just more things to the language. Of course, some people don't buy a new cellular phone because next year you get a twice cooler one for half the price. Or they don't buy a new computer "because they're getting cheaper and stronger all the time, so for every month I push back buying one, I actually earn money". You might as well skip waiting alltogether, because (as with any programming language) the day /will/ come when D is obsolete. But then you shouldn't marry either, because one day she'll either divorce you or die. In reality, you might get a lot of things done in D1 while waiting, and possibly even enjoy both the programming, and the results of it.

I would disagree with this specifically in relation to const, enum and the current peices here as once the state of this entire concurrent programming underpinnings are complete I would both hope and assume the standard libraries would embrace them and become threadsafe, happy and productive(unless we are going to have two libraries, std and stdconst. On your last note about waiting, D will eventually become obsolete, this is true. However we already have dangling in front of us a fall freeze date(tentative I know) which includes alot of features people are holding their breath over. D1.0 lacks alot of features people seem to want. Also code maintenance/expansion is easier when you have the widest selection of libraries to choose from. and 2 years from now it wont be D1 people are writing said libraries to. It will probobly be D2 or D3. I think alot of people are waiting for the core of the language to be frozen where only new stuff gets mucked with. not existing keywords, precidents and features.
Apr 11 2008
next sibling parent Georg Wrede <georg nospam.org> writes:
Hans W. Uhlig wrote:
 Georg Wrede wrote:
 
 Hans W. Uhlig wrote:

 Jarrett Billingsley wrote:

 "Alex Burton" <alexibu mac.com> wrote in message 
 news:ftjfrg$24lu$1 digitalmars.com...

 Jarrett Billingsley Wrote:

 "Alex Burton" <alexibu mac.com> wrote in message
 news:fti5dd$8h7$1 digitalmars.com...

 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.

What? What does constness in D2 have anything to do with D1?

next version makes me hesitant to start writing lots of code in D1.

The entire reason for making D1 _D1_ was so that people _would_ start using it. It strikes me as very odd that the exact opposite seems to have happened. You're not the only one to come to this decision. Personally I won't even consider D2 until it's frozen. Furthermore just because you write code in D1 doesn't mean you'll _have_ to start using D2.

I think this idea comes out of the same mindset as Java. You don't want to use something you know is going to be deprecated so soon down the road. Since D2.0 is an evolution of the product rather then a new language it is seen as the next version, why write something that wont work with the next version when you can write it for that version. I think its simply the fact that D2 isn't backwards compatible for a good chunk of things. Porting might end up being a bigger pain then simply waiting is. I look forward to a lot of the changes in parallel processing and library support coming for D2 and am waiting to start a few projects until D2.0s feature set is frozen, till then I merely putter.

But nobody knows when that'll happen! It might be months, but it might as well be late /next/ year. And if you do regular (as in just normal) programmin in D1, chances that you'd have to work hard to later port it to D2 are small. Most of the things in D1 aren't going to change anyway. There'll mostly be just more things to the language. Of course, some people don't buy a new cellular phone because next year you get a twice cooler one for half the price. Or they don't buy a new computer "because they're getting cheaper and stronger all the time, so for every month I push back buying one, I actually earn money". You might as well skip waiting alltogether, because (as with any programming language) the day /will/ come when D is obsolete. But then you shouldn't marry either, because one day she'll either divorce you or die. In reality, you might get a lot of things done in D1 while waiting, and possibly even enjoy both the programming, and the results of it.

I would disagree with this specifically in relation to const, enum and the current peices here as once the state of this entire concurrent programming underpinnings are complete I would both hope and assume the standard libraries would embrace them and become threadsafe, happy and productive(unless we are going to have two libraries, std and stdconst. On your last note about waiting, D will eventually become obsolete, this is true. However we already have dangling in front of us a fall freeze date(tentative I know) which includes alot of features people are holding their breath over. D1.0 lacks alot of features people seem to want. Also code maintenance/expansion is easier when you have the widest selection of libraries to choose from. and 2 years from now it wont be D1 people are writing said libraries to. It will probobly be D2 or D3. I think alot of people are waiting for the core of the language to be frozen where only new stuff gets mucked with. not existing keywords, precidents and features.

When D2 is ready, then people start writing or porting libraries to it. That won't happen overnight. And until then, you can't start using it "at full strength". And before those libraries are ready, already ideas and must-haves for D3 are widely discussed here and in other places. Those must-haves will feel just as important as the ones we want today, that is, you can't live without them. So, again, you'd have to wait for the next D version, and its libraries, and by that time D4 will be in the pipelines. I'm sorry to say, that simply is the way things are. And that will never change. And we don't even want that to change. Other languages evolve, computers get faster and bigger, and what people take for granted as language properties changes too.
Apr 11 2008
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Hans W. Uhlig" wrote
 I would disagree with this specifically in relation to const, enum and the 
 current peices here as once the state of this entire concurrent 
 programming underpinnings are complete I would both hope and assume the 
 standard libraries would embrace them and become threadsafe, happy and 
 productive(unless we are going to have two libraries, std and stdconst.

Note that pure functions, which are the only thing that allows automatic concurrency (thread safety can be had now in D1), is not planned AFAIK until D3. D2 only brings us const as a tool for developers, not for thread safety. -Steve
Apr 11 2008
prev sibling next sibling parent reply "Craig Black" <cblack ara.com> writes:
 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 :

Correct me if I'm wrong, but I read in an article that there are simple optimizations that can be performed by C++ compilers using const. For example this is preferred: const int size = container.size(); for(int i = 0; i < size; i++) { ... } rather than this: int size = container.size(); for(int i = 0; i < size; i++) { ... } Because it gives the compiler assurance to know that the size will not change during the loop. -Craig
Apr 09 2008
parent Alex Burton <alexibu mac.com> writes:
Craig Black Wrote:

 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 :

Correct me if I'm wrong, but I read in an article that there are simple optimizations that can be performed by C++ compilers using const. For example this is preferred: const int size = container.size(); for(int i = 0; i < size; i++) { ... } rather than this: int size = container.size(); for(int i = 0; i < size; i++) { ... } Because it gives the compiler assurance to know that the size will not change during the loop.

container is likely to be a container like vector<T> which is a template, which allows the compiler to see what is actually in the size() function. If all we had was an interface to container, then the compiler couldn't assume that there wasn't a perfectly legal mutable member in there that changed each time size was called, or that the result of size is coming from some other class not part of the container. Both of these are weaknesses that Walter points out with C++ const system, and he is right, but unfortunately transitive const doesn't fix it. Alex
Apr 09 2008
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Alex Burton" wrote
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 invariant is what allows for optimizations using pure functions. In fact, transitive invariant isn't needed, just a well defined invariance system is needed. Transitive invariant helps because it's usually what one usually means when one declares a member of a class. For example, if I declare a class like: class C { int * member; pure invariant int f() { return *member; } } If D's invariant system isn't transitive, it means that just because I declare a C as invariant doesn't make what the members reference invariant. Then the pure function isn't allowed to dereference member, because it's not sure if member is invariant or not. We can add keywords to declare that a member should be invariant if the class is invariant, but then the author of the class has to know that his class will be used in pure functions. If the author doesn't care, then another author writing a pure function cannot use C's members, even if C is invariant, and what we are left with is a bunch of code that doesn't work with pure functions. The goal is to make FP possible, not hinder it. What we want is to have what is most common be the default, that any variable declared inside a class is part of the class by default, and therefore, affected by transitive const/invariant. We already have exceptions that say 'this isn't part of the class', such as static. What we don't have yet is a way to declare that a variable is not part of the class but is stored with the class instance.
 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.

You are saying, let's have variables declared inside a class NOT be considered part of the class unless you use the 'part' keyword? While this is a way to solve the problem, I think this would be very error prone. What most people are used to is that when they declare a variable inside a class scope, by default it's a member of the class instance. With your scheme, what you will end up with is people will seldom use the 'part' keyword, and when pure functions come around, they cannot use any of the non-'part' members. As a result, nobody will use pure functions except for simple math functions. This is not what Walter wants, and if we are going to have pure functions, it's not what I want either. I like how D const is transitive by default, although I think there should be a way to make exceptions to that rule. -Steve
Apr 09 2008
parent Alex Burton <alexibu mac.com> writes:
Steven Schveighoffer Wrote:

 "Alex Burton" wrote

 
 If D's invariant system isn't transitive, it means that just because I 
 declare a C as invariant doesn't make what the members reference invariant. 
 Then the pure function isn't allowed to dereference member, because it's not 
 sure if member is invariant or not.  We can add keywords to declare that a 
 member should be invariant if the class is invariant, but then the author of 
 the class has to know that his class will be used in pure functions.  If the 
 author doesn't care, then another author writing a pure function cannot use 
 C's members, even if C is invariant, and what we are left with is a bunch of 
 code that doesn't work with pure functions.  The goal is to make FP 
 possible, not hinder it.
 
 What we want is to have what is most common be the default, that any 
 variable declared inside a class is part of the class by default, and 
 therefore, affected by transitive const/invariant.
 
 We already have exceptions that say 'this isn't part of the class', such as 
 static.  What we don't have yet is a way to declare that a variable is not 
 part of the class but is stored with the class instance.
 
 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.

You are saying, let's have variables declared inside a class NOT be considered part of the class unless you use the 'part' keyword? While this is a way to solve the problem, I think this would be very error prone. What most people are used to is that when they declare a variable inside a class scope, by default it's a member of the class instance. With your scheme, what you will end up with is people will seldom use the 'part' keyword, and when pure functions come around, they cannot use any of the non-'part' members. As a result, nobody will use pure functions except for simple math functions. This is not what Walter wants, and if we are going to have pure functions, it's not what I want either. I like how D const is transitive by default, although I think there should be a way to make exceptions to that rule.

I agree, the most common case should be the default. The concept would stay the same though. Whether the keyword is part or notpart or something else I don't know. The basic concept is that reality tells us that not every part of a piece of software is part of every class. Transitive const is at odds with reality, because it assumes that all objects that are members of a class are necessarily part of that class. Alex
Apr 09 2008