D - more or less power than C++?

[Tyro]

Johan Granberg wrote:
> Ben Phillips wrote:
> 
>> In article <dubpge$u3r$1 at digitaldaemon.com>, Johan Granberg says...
>>
>>>>> 1. const parameters and member functions
>>>>>
>>>>> Countless times this saved me. I just can't imagine references being
>>>>> passed in and out of functions without something explicitly saying 
>>>>> that
>>>>> the function is expected or not to modify it.
>>>
>>> You did not answer the above statement and i have seen this repeated 
>>> all over this thread along with destructors in structs.
>>>
>>
>> A method can explicitly say that it will modify a reference by using 
>> "out" and
>> "inout".
>>
>> I've never cared much for const member methods, so I'm confused as to 
>> how a lack
>> of them can cause such a problem. Can you give an example?
>>
>>
> It is not const methods so much as const in parameters.
> 
> class A
> {
>  int bar=1;//bar should bee read only
> }

And why exactly should this be read only again? Maybe my primitive brain 
is completely underdeveloped rendering me incapable of grasping the 
concept. Nonetheless, it strikes me as only natural that if one wants 
something to be read only one would simply identify it as such:

class A
{
   const int bar=1; // bar IS read only
}

but maybe I'm missing something here. Reading on!!!

> void foo(in i a)//I want a to bee readonly
> {
>     i.bar=2;//here the value should not be writable but since a is
>             //a reference it is
> }
 >
> A a=new A;//bar is 1
> foo(a);
> print(a.bar);//prints 2

Oh, I see, you want the in parameter to treat it as if it were read 
only. Rightly so. One should not be able to modify an "in" parameter 
(reference or otherwise). It is the implied behavior when using the in 
keyword, there it is only reasonable to expected it. I do not think this 
is a problem with the implementation of const however, but rather a 
glaring defect in the implementation of "in".

> It is not so very usefull in smal examples but if you have a large 
> program and do that by mistake it could cause a bug. Basicaly it is a 
> message from the writer of a class to it's users of how member are to 
> bee used, and aditionaly it has compiler suport to catch typos and 
> mistakes, if a user realy want to change the data against the orginal 
> authors recomendations he can use a explicit cast.

Andrew