The problem with const proposals

[Jason House]

Walter Bright Wrote:
> So, what are our axioms for const/invariant?
> 
> 1) Const/invariant are transitive.
> 2) Any type T can be wrapped inside a struct S, and that S can be made 
> to behave as a typedef for type T.
> 3) The contents of invariant types, once constructed, can never change.
> 4) The contents of const types, once constructed, can never be changed 
> through those const contents.
> 5) For any type T, we can construct a const(T) or an invariant(T) 
> without knowing anything about T.

I'd like to see a list of goals that drive axiom development.  The list below includes some of the stuff posted by others plus additional stuff.
(a) simple to understand
(b) nice, intuitive syntax
(c) compatible with generic programming
(d) compatible with functional programming
(e) compatible with compiler optimization
(f) const guarantees for API's

I'm not sure where axiom 2 comes from.  I believe the requirement for invariant comes in from (d) and (e) while the requirement for const comes from (f).

I'd love to see "const X" == "const(X)" as an axiom ;)

In the past, when considering const, I found it very helpful to think about when implicit casts to (scoped) const/invariant are valid.  I believe that in the current design, there's no way for the compiler to guarantee that a cast to invariant is valid because there's never a guarantee that a non-invariant bit of data will be written to by something else.  IMHO, having well defined cases when casting is safe should be another requirement.