Do we really need const?

[Robert Fraser]

Lionello Lunesu Wrote:

> void bar() throw;
> void foo() { bar(); }//ERROR, bar can throw
> void foo2() throw { bar(); } //OK
> void foo3() throw { bar() throw; } //OK ("cast")

In other words, all exceptions are checked exceptions...? This would especially be a problem since all allocations can throw exceptions unless caught. This sounds like it would introduce MORE problems than Java's checked exceptions. I think the "safe" case sis typically the marked one (i.e. Walter's "nothrow" he mentioned at the conference, const, pure, etc.).

The whole red code-green code idea isn't bad, but I think that should generally be relegated to documentation instead of making the compiler check it.

There seems to be a general push (among many computer scientists) to enforce stricter rules, yet some of the most successful languages in the past few years have been dynamically/duck typed. The price is that the impetus of using the code correctly falls on the programmer and not the compiler/interpreter. The reward is much greater productivity, since the programmer doesn't need to be concerned about such things as const-correctness, checked exceptions or interface specification, she just works with the knowledge the compiler trusts her enough to do the right thing.

I'm not suggesting D go dynamically-typed (doesn't work so well in a compiled language), but restrictions for the sake of restrictions should be looked upon with great care. If const or pure can help optimization and make paralell programming easier, I'm all for it, but if it'll just sit there and make my life harder then it's not worth it.

I'd like to pose a question to those who have used C++'s const: do you feel that it has saved more time by preventing bugs than it has taken by being forced to type it all the time, and the time spent when it has to be removed all throughout a hierarchy, as inevitably has to happen at least once? That is, const-correctness is a time investment, so do you feel that investment has paid off for you?

I can say that working in Java, I have _never_ felt that if I pass a class reference that was "constant" in nature to a method written by somebody else or even to entirely different subsystem, that the invariantness contract, specified only in the documentation, would be broken. Compiler checks in that case end up being as useless and annoying as checked exceptions.