Walter wrote:

>"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message
>news:c7l3hk$1hm9$1@digitaldaemon.com...
>  
>
>>1. I accept that it complicates the compiler
>>2. I have used it for 14 years, and it has helped on countless occasions.
>>    
>>
>I would
>  
>
>>estimate it to be at least in the 10,000s.
>>    
>>
>
>I won't dispute that you find it useful. But useful for what? Making a
>program const-correct? Is that a circular requirement <g> ? I have gone
>through the exercise of making large programs const-correct. Were there a
>lot of const-correct errors? Yes, hundreds. Were any of them a bug? Nope.
>Not one. On the other hand, when C added function prototyping, that was a
>huge win in eliminating bugs (it was such a huge win that my compiler
>implemented a lint-like 'autoprototyping' feature for K&R code, which found
>bug after bug). No such win happened when const was added.
>
>  
>
>>3. I don't care what it looks like, and don't find it ugly because I'm
>>    
>>
>used to
>  
>
>>using it. The same could be said for any syntax - other than VB, and K&R
>>bracing - and these things are, IMO, highly irrelevant.
>>    
>>
>
>I strongly disagree that the aesthetics are irrelevant. In my experience,
>there's a strong correlation between code that looks good and code that
>works well. Aesthetics have been a major factor in the design of D - I want
>D code to look good on the page. That's why I agonized for such a long time
>trying to find a template syntax that looked good (C++'s does not). I enjoy
>reading other peoples' code when they spend the time to make it look good.
>If it looks ugly, I don't want to read it.
>  
>
What about if "in"'d objects members and array members where made const automaticly?  You wouldn't need a keyword at all and it would fill most of the gaps in D not having const.

ie
class A
{
int t;

void func() {}

void func2() {t = 10;}

}

void func(A a)
{
   a.func(); //ok
   a.t = 10; //not ok
   a.func2(); //not ok
   a = new A(); //ok but won't be returned
}

void func(int [] a)
{
   a[10] = 5; //not ok
   a.length = 20; //not ok
}

Of course you'd have all the problems with determining if a member is actually changing something or not.

-- 
-Anderson: http://badmama.com.au/~anderson/

On Mon, 10 May 2004 09:01:34 +0800, J Anderson wrote:
> What about if "in"'d objects members and array members where made const automaticly?  You wouldn't need a keyword at all and it would fill most of the gaps in D not having const.

I like this a lot, myself. In fact, I had wondered why 'in' parameters were not const already. I would suggest a middle ground: methods can be const, like:

class A {
int foo() const;
}

And then have all 'in' parameters automatically be const. That would require vastly less magic to detect non-const function calls. Thoughts?

Mike Swieton
__
So he thought it was impossible, and told me not to do it. So I did it anyway.
	- Warren Robinett

Mike Swieton wrote:

>On Mon, 10 May 2004 09:01:34 +0800, J Anderson wrote:
>  
>
>>What about if "in"'d objects members and array members where made const automaticly?  You wouldn't need a keyword at all and it would fill most of the gaps in D not having const.
>>    
>>
>
>I like this a lot, myself. In fact, I had wondered why 'in' parameters were
>not const already. I would suggest a middle ground: methods can be const,
>like:
>
>class A {
>int foo() const;
>}
>
>And then have all 'in' parameters automatically be const. That would require
>vastly less magic to detect non-const function calls. Thoughts?
>
>Mike Swieton
>__
>So he thought it was impossible, and told me not to do it. So I did it anyway.
>	- Warren Robinett
>
>  
>
I would like not to have to type const at all.  You'd think the compiler could be smart enough to work out which methods are const.  Of course, if someone changes the specifications of a function (forgets it's used as const), then there will be trouble.

-- 
-Anderson: http://badmama.com.au/~anderson/

In article <c7m7uq$33k$1@digitaldaemon.com>, Walter says...
>
>"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:c7l3hk$1hm9$1@digitaldaemon.com...
>> 1. I accept that it complicates the compiler
>> 2. I have used it for 14 years, and it has helped on countless occasions.
>I would
>> estimate it to be at least in the 10,000s.
>
>I won't dispute that you find it useful. But useful for what? Making a program const-correct? Is that a circular requirement <g> ? I have gone through the exercise of making large programs const-correct. Were there a lot of const-correct errors? Yes, hundreds. Were any of them a bug? Nope.

The one time that I found it useful is for serialization: if you need to use read-only and read-write locks to serialize access to parts of a struct, then you need to know who is modifying and who is not.

I was able to solve this for a large C++ module by making methods const and using "read-write" only on the modules that the compiler choked on.

So it helped a little; Not that this alone justifies it.

But some kind of analysis to prevent "in" parameters from being copied when they are not modified might be nice.

Kevin

J Anderson wrote:
> I would like not to have to type const at all.  You'd think the compiler could be smart enough to work out which methods are const.  Of course, if someone changes the specifications of a function (forgets it's used as const), then there will be trouble.

1. The compiler will never be able to track which values are const. This might work if you do full inlining and full data flow analysis, but as soon as you pass around parameters between functions, the compiler will be lost.

2. Even if the compiler were able to do such a thing, it would miss the point: The "const" discussion is not about optimization, but far more important, about safety and documentation. Just think of "const" as a special kind of a contract, that can even be checked by the compiler.

In article <c7n5ir$1c2p$1@digitaldaemon.com>, Kevin Bealer says...
>
>In article <c7m7uq$33k$1@digitaldaemon.com>, Walter says...
>>
>>"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:c7l3hk$1hm9$1@digitaldaemon.com...
>>> 1. I accept that it complicates the compiler
>>> 2. I have used it for 14 years, and it has helped on countless occasions.
>>I would
>>> estimate it to be at least in the 10,000s.
>>
>>I won't dispute that you find it useful. But useful for what? Making a program const-correct? Is that a circular requirement <g> ? I have gone through the exercise of making large programs const-correct. Were there a lot of const-correct errors? Yes, hundreds. Were any of them a bug? Nope.

(cough) In this case, by "serialization" I meant synchronizing between threads,
not marshalling data.

>The one time that I found it useful is for serialization: if you need to use read-only and read-write locks to serialize access to parts of a struct, then you need to know who is modifying and who is not.
>
>I was able to solve this for a large C++ module by making methods const and using "read-write" only on the modules that the compiler choked on.
>
>So it helped a little; Not that this alone justifies it.
>
>But some kind of analysis to prevent "in" parameters from being copied when they are not modified might be nice.
>
>Kevin
>
>

Norbert Nemec wrote:

>J Anderson wrote:
>  
>
>>I would like not to have to type const at all.  You'd think the compiler
>>could be smart enough to work out which methods are const.  Of course,
>>if someone changes the specifications of a function (forgets it's used
>>as const), then there will be trouble.
>>    
>>
>
>1. The compiler will never be able to track which values are const. This
>might work if you do full inlining and full data flow analysis, but as soon
>as you pass around parameters between functions, the compiler will be lost.
>  
>
Normally in C++ every const function is checked for constnes .  All I'm saying is that every function could be checked for constness and then const added to the definition in the object file/lib file.  If what your saying is correct, the compiler would never be able to certify that a const is indeed correct in the first place.

>2. Even if the compiler were able to do such a thing, it would miss the
>point: The "const" discussion is not about optimization, but far more
>important, about safety and documentation. Just think of "const" as a
>special kind of a contract, that can even be checked by the compiler.
>  
>
I already pointed that out.

-- 
-Anderson: http://badmama.com.au/~anderson/

J Anderson wrote:

> Norbert Nemec wrote:
>>
>>1. The compiler will never be able to track which values are const. This might work if you do full inlining and full data flow analysis, but as soon as you pass around parameters between functions, the compiler will be lost.
>> 
> Normally in C++ every const function is checked for constnes .  All I'm saying is that every function could be checked for constness and then const added to the definition in the object file/lib file.  If what your saying is correct, the compiler would never be able to certify that a const is indeed correct in the first place.

The compiler can check it, if it has access to all the code. If I understand it correctly, in D, this is always the case. Otherwise, const would clearly have to be part of the interface of a module. I guess, I'm just not happy about the idea of mixing interface and implementation in the way D does it.

Norbert Nemec wrote:

>J Anderson wrote:
>
>  
>
>>Norbert Nemec wrote:
>>    
>>
>>>1. The compiler will never be able to track which values are const. This
>>>might work if you do full inlining and full data flow analysis, but as
>>>soon as you pass around parameters between functions, the compiler will be
>>>lost.
>>> 
>>>      
>>>
>>Normally in C++ every const function is checked for constnes .  All I'm
>>saying is that every function could be checked for constness and then
>>const added to the definition in the object file/lib file.  If what your
>>saying is correct, the compiler would never be able to certify that a
>>const is indeed correct in the first place.
>>    
>>
>
>The compiler can check it, if it has access to all the code. If I understand
>it correctly, in D, this is always the case. Otherwise, const would clearly
>have to be part of the interface of a module. I guess, I'm just not happy
>about the idea of mixing interface and implementation in the way D does it.
>  
>
If D had an optional interface like C++, then you would put it in the interface manually.  Since D automaticly generates an invisible interface it could include it automaticly.

-- 
-Anderson: http://badmama.com.au/~anderson/

In article <c6ma69$2i1m$1@digitaldaemon.com>, hellcatv@hotmail.com says...
>
>Hello, I've been completely enthusiastic by what I've seen about D, and am considering porting some of my projects to D.
>
>However, one thing does come to mind that I wished to ask about: Const member functions.
>
>As a C++ programmer I have found it extremely useful to have const member functions.

I feel exactly the same. The D is very promising for me, but lack of const methods and parameter modifiers are fly in the ointment. The const plays significant role in design of my applications for many yeas.

Walter, could You please, change your mind eventually. As I see many of your language's users need this feature badly.

Thanks.

-- serg