Yes or No? Discuss!

Five tons of flax.

Ah, I miss const correctness. It was sort of like a little puzzle to play with while you wrote tedious low-level code.

Ah. I was kind of hoping for some enlightened discussion of the topic.

It helps you out by spitting out errors when you get confused, what else is there to say?

Useful for what it is: something to help keep you from screwing up. Obviously due to aliasing rules it has no real functional significance, but you know, the same can be said for a lot of syntactic stuff we use. It helps you, the programmer, write code that doesn't change variables behind the backs of other functions.

I think it makes the code somewhat more readable for other people, if used propertly (ie, don't bypassing it ), since you can explicitly state that a function doesn't have side effects (though it can still touch global variables, but you don't have those ) or modify the object.

It would be more useful if it couldn't be bypased, and that method couldn't modify global variables or call global/static functions since that would allow compilers to do some optimizations.

Const correctness is misleading, to say the least. It's entirely possible to think that an object is const, whereas some local context uses it as non-const.

What is better is pureness (the whole context being const).

i. hate. constants. They are a jerk to have to deal with, especially when a functions asks for a constant and i need to use a non-constant (which doesn't happen often, honestly)

but I wish that constants didnt exist, and they were just regular variables.

and dislike static too. But I only hate static because I have yet to figure out how to deal with them in cases other than them being functions. >.<

just wanted to say that. I know that pro-programmers must use them all the time for time saving techniques and have no problem, I'm sure. But am I pro? No. puts on flame retardant suit

I like const-correctness. I certainly use it in C++ (and C?). Whether it's truly useful or not, I can't say. I think it is, but I could be wrong. I wish a similar, though updated, concept existed in C#. I think in modern, managed languages, the compiler should disallow casting constness away. That way, you could actually rely on the concept. If you declare a variable as const (or cast to const) then you could rely on it not being modified no matter what^[1]. That would be kind of nice, I think.

Truly immutable types are possible and desirable in general (several languages have them), but it doesn't work for practical reasons in C or C++ due to aliasing.

In C/C++, constness is not really about the type itself, but about the function acting upon an instance of a type. When you declare a function as taking a const something, you're saying "I promise not to modify this variable in any way". It's a kind of primitive contract rather than a type feature. You can still violate that contract if you really want to, but you have to actually explicitly say when you do by using a const cast, making accidental changing of objects much less likely.

You can get some measure of constness in .NET by marking fields as readonly. The convention is for structs to be completely readonly, so if you follow that guideline then you've got a set of immutable types.

So we can accomplish A, but only for fields of classes or structs. B and C, I think, are becoming less of a problem as side-effects make code harder to test. I find myself writing code in a more functional style when I'm doing TDD.

I understand there are situations where const allows for extra optimizations.

in haskell everything is a const.

I've just noticed that in C++ its used a lot whenever a parameter is passed to a method, especially when working with overloading operators. I never work with the latter and rarely use const but if you don't want a method to change the object being passed then const is the best option, besides saving a copy before passing the object. Very useful indeed, I wonder if Java has a similar problem, most likely not but feel free to let me know.