Stepping back and looking at constness from another angle.

[Ary Manzana]

I also get very confused about const, final, invariant... and I think 
I'm beggining to understand why (I get confused).

Algorithms describe what should be done, and also which variables and 
structures are needed in order to "execute" them. I've never seen an 
algorithm's pseudocode saying something like "and this var's content 
can't change" "this reference can't change", or "now do foo(bar), where 
bar dosen't change it's contents". The only point I see in marking 
variables as const or such, is for allowing compiler optimizations. So 
adding keywords to a language just to allow compiler optimizations seems 
strange to me.

If you can't mark a function parameter as const in the language, you can 
always put a big warning comment saying "Hey, don't modify this array's 
content" and that's it. Documentation exists for this reason. So what if 
you write an interface and somebody implements it in the wrong way? It's 
like trying to document what a function in a interface should do, and 
enforcing the compiler to check this. Something llike

int double(int x) does(returnsDouble) {
   return 3*x; // error, 3*x is not allowed because of returnsDouble
}

Carlos Santander escribió:
> Sean Kelly escribió:
>>
>> The proposed changes are actually pretty decent from a conceptual 
>> standpoint but I don't like the syntax.  Using three synonyms to 
>> represent different facets of const behavior kind of stinks.  I'm sure 
>> I'll get used to it with practice, but I worry that the const features 
>> will hurt readability for those new to the language, and will 
>> complicate code in the general case for little actual gain.
>>
> 
> Not only for those new to the language, but for less experienced 
> programmers too.
> 
> I know some C++, but I've never done anything serious with it. Thus, 
> since I don't use it, I don't know what all those "const" do (once I 
> read about it in some manual or something, but I no longer remember.) 
> So, while I understand the problem at hand here, I still get confused 
> over the syntax, even if I'm not new to the language, there have been so 
> many discussions about that problem here, and the syntax has been 
> explained so many times.
> 
> For example, yesterday Walter posted a message that included this line:
> 
> invariant(char)[new] ret = "prefix";
> 
> I understand it as "ret can't change." However, later on, on the same 
> snippet, he appended to "ret." Not to mention that when I first read it, 
> I had no idea what it was. I still don't know why those () are there and 
> not somewhere else. Please don't try to explain to me; I guess it'll be 
> clear once I start using it, but right now, I'm just trusting those who 
> have walked this road before.
> 
> Finally, I wouldn't know how to explain it to someone who's just 
> starting in programming. Again, maybe it's because I myself don't 
> understand it, but bear with me for a moment. I don't think it'll be 
> immediately crystal clear for everyone that in an array you can or can't 
> change the length, the pointer, the contents, all of them, none of them, 
> or some of them, and that the keyword you use is the one that defines 
> that, that the keywords available are very close in meaning, and that 
> using or not using parentheses also changes the meaning.
> 
> I'm sorry if it sounded over-dramatical; it certainly wasn't my 
> intention. Bottom line is, I'm really hoping that it turns out well, and 
> that I can understand it when it's out.