How this fits with common objections

[Reiner Pope]

This is a safe static checking system, so the only way to work around it 
is via some form of dirty hacks. However, it is much safer than C++, 
because it provides a form of deep constness, and the extra flexibility 
of this system should further avoid the need for const_cast.

The rocheck type also works with copy-on-write functions, which solves 
an objection which I raised earlier about most static checking methods 
requiring extra dups on these functions.

To quote Walter from earlier:
> Const has a number of issues whether or not it is default:
> 
> 1) function parameters that are reference types (what is talked about most here) being const
> 2) member functions being able to modify the object instance (const functions)
> 3) const in the return value
I'm not sure I understand the problems he discusses, but I believe that 
the assignability/mutability distinction covers those problems.
> 4) what happens if both const and non-const references to the same data are simultaneous, and one modifies through the non-const one?
This seems to be a different issue: thread-safety. The important thing 
is ensuring that the functions you call only have a readonly view of the 
data you give them.
> 5) assignment of a const reference to a non-const one, either explicitly or through a function parameter
This is an implicit cast to a subtype, and isn’t a problem. It can’t 
cause a const-violation, and any programmer problems it causes are 
probably actually bugs caught at compile-time instead of just annoyances.
> 6) what happens if one returns a const reference
I have no idea why this is a problem. It seems to be an essential feature.

> One way to do it is to have const-as-type-modifier like C++, something I've tried to avoid as being excessively complex (compiler and programmer) and ugly.
Complexity for the compiler is something I can’t judge. For the 
programmer, however, const-checking seems to be an essential feature for 
safety and speed. I think much of the ugliness of having many const’s 
all over the place can be largely avoided by using const-by-default and 
const inference as part of type inference. The rotemplate/romaybe 
mechanism also avoids most of the need for duplicate code which C++ 
requires.

> (An indirect quote, since I can't find the original) The objection about ‘too much water under the bridge’ with regards to const by default:
I am disappointed that this would be a deterrent to such an important 
language feature. I understand that Walter doesn’t value const as much 
as others, but so many people see const as important that such a 
dismissal is not enough. As discussed earlier, const by default should 
actually break the /least/ code and although introducing another form of 
const may not _break_ the code, it will probably just hide the problems 
until someone wants to make it const-aware. Furthermore, now is the best 
time to make breaking changes, since breaking changes after 1.0 are a 
big no-no.

> The objection about making const-unaware code const-aware:
The hassle of this should be almost eliminated since const by default 
practically forces people to write const-correct code anyway.