Stepping back and looking at constness from another angle.

Carlos Santander csantander619 at gmail.com
Tue Jun 5 20:45:44 PDT 2007


Ary Manzana escribió:
 > 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.
 >

I agree with this...

 > 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
 > }
 >

... but not with this. While it's still over my head, I see the 
const-correctness thing similar to type-safety. There're languages where you say:

// returns a string
function foo ()
{
     return "foo";
}

And it works, and you don't want the compiler/interpreter to be bugging you. But 
at some point you want type-safety, even if only to make the comment and the 
implementation match.

My point is, I don't think that's the purpose of documentation.

There is one thing, however, and it is when everything gets carried away. Where 
do you draw the line between just documenting and actually implementing it as a 
language feature? For example, "throws" in Java, which is non-existent in D. 
Here, (almost) everyone agreed that it was best to leave it as documentation 
only. Nonetheless, the same argument I just applied for type-safety and 
const-correctness could be applied to "throws," so I guess it's a matter of 
preference or background, maybe?

-- 
Carlos Santander Bernal




More information about the Digitalmars-d mailing list