digitalmars.D - Another Transitive const solution
- Alex Burton (58/58) Apr 09 2008 I wonder how many lurkers like me are waiting for D 2.0s const system to...
- Janice Caron (5/7) Apr 09 2008 Just curious, but what exactly are you waiting for? Are you waiting
- Jarrett Billingsley (3/10) Apr 09 2008 What? What does constness in D2 have anything to do with D1?
- Alex Burton (2/14) Apr 09 2008 Knowing that fundamental changes to the language will come in the next v...
- Jarrett Billingsley (7/24) Apr 09 2008 The entire reason for making D1 _D1_ was so that people _would_ start us...
- Hans W. Uhlig (12/41) Apr 10 2008 I think this idea comes out of the same mindset as Java. You don't want
- Georg Wrede (17/66) Apr 10 2008 But nobody knows when that'll happen!
- Alex Burton (9/82) Apr 11 2008 I know what you mean - you can't put off buying a computer till the next...
- Hans W. Uhlig (16/89) Apr 11 2008 I would disagree with this specifically in relation to const, enum and
- Georg Wrede (14/109) Apr 11 2008 When D2 is ready, then people start writing or porting libraries to it.
- Steven Schveighoffer (6/11) Apr 11 2008 Note that pure functions, which are the only thing that allows automatic...
- Craig Black (11/16) Apr 09 2008 Correct me if I'm wrong, but I read in an article that there are simple
- Alex Burton (6/28) Apr 09 2008 I am not an expert on such things but :
- Steven Schveighoffer (43/110) Apr 09 2008 transitive invariant is what allows for optimizations using pure functio...
- Alex Burton (6/73) Apr 09 2008 I agree, the most common case should be the default. The concept would s...
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
"Janice Caron" <caron800 googlemail.com> 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
"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
Jarrett Billingsley Wrote:"Alex Burton" <alexibu mac.com> wrote in message news:fti5dd$8h7$1 digitalmars.com...Knowing that fundamental changes to the language will come in the next version makes me hesitant to start writing lots of code in D1.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
"Alex Burton" <alexibu mac.com> wrote in message news:ftjfrg$24lu$1 digitalmars.com...Jarrett Billingsley Wrote: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."Alex Burton" <alexibu mac.com> wrote in message news:fti5dd$8h7$1 digitalmars.com...Knowing that fundamental changes to the language will come in the next version makes me hesitant to start writing lots of code in D1.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
Jarrett Billingsley wrote:"Alex Burton" <alexibu mac.com> wrote in message news:ftjfrg$24lu$1 digitalmars.com...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.Jarrett Billingsley Wrote: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."Alex Burton" <alexibu mac.com> wrote in message news:fti5dd$8h7$1 digitalmars.com...Knowing that fundamental changes to the language will come in the next version makes me hesitant to start writing lots of code in D1.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 10 2008
Hans W. Uhlig wrote:Jarrett Billingsley wrote: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."Alex Burton" <alexibu mac.com> wrote in message news:ftjfrg$24lu$1 digitalmars.com...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.Jarrett Billingsley Wrote: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."Alex Burton" <alexibu mac.com> wrote in message news:fti5dd$8h7$1 digitalmars.com...Knowing that fundamental changes to the language will come in the next version makes me hesitant to start writing lots of code in D1.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 10 2008
Georg Wrede Wrote:Hans W. Uhlig wrote: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. AlexJarrett Billingsley wrote: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."Alex Burton" <alexibu mac.com> wrote in message news:ftjfrg$24lu$1 digitalmars.com...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.Jarrett Billingsley Wrote: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."Alex Burton" <alexibu mac.com> wrote in message news:fti5dd$8h7$1 digitalmars.com...Knowing that fundamental changes to the language will come in the next version makes me hesitant to start writing lots of code in D1.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 11 2008
Georg Wrede wrote: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. 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.Jarrett Billingsley wrote: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."Alex Burton" <alexibu mac.com> wrote in message news:ftjfrg$24lu$1 digitalmars.com...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.Jarrett Billingsley Wrote: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."Alex Burton" <alexibu mac.com> wrote in message news:fti5dd$8h7$1 digitalmars.com...Knowing that fundamental changes to the language will come in the next version makes me hesitant to start writing lots of code in D1.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 11 2008
Hans W. Uhlig wrote:Georg Wrede wrote: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.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. 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.Jarrett Billingsley wrote: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."Alex Burton" <alexibu mac.com> wrote in message news:ftjfrg$24lu$1 digitalmars.com...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.Jarrett Billingsley Wrote: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."Alex Burton" <alexibu mac.com> wrote in message news:fti5dd$8h7$1 digitalmars.com...Knowing that fundamental changes to the language will come in the next version makes me hesitant to start writing lots of code in D1.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 11 2008
"Hans W. Uhlig" wroteI 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
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
Craig Black Wrote:I am not an expert on such things but : 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. AlexGoals 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.
Apr 09 2008
"Alex Burton" wroteI 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
Steven Schveighoffer Wrote:"Alex Burton" wroteIf 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.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. AlexTransitive 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.
Apr 09 2008