const?? When and why? This is ugly!

[Burton Radons]

Walter Bright Wrote:

> Burton Radons wrote:
> > That's what we said about strings in 1.0. You modify it, you copy it,
> > or you tell the user. The gentleman's agreement worked perfectly and
> > that came without a mess of keywords, without implicit or explicit
> > restrictions on behaviour, without having to condition templates.
> 
> The one flaw in it was the behavior I consistently saw of "I'm copying 
> the string just to be sure I own it and nobody else changes it." D was 
> meant for copy-on-write, which means copy the string *only* if you 
> change it. No defensive copying. No "just in case" copying. The 
> gentleman's agreement failed as far as I could tell.
> 
> With immutable strings, the gentleman's agreement is enforced.

Am I going to become a broken record on this? Because "invariant (char) []" is the string type, data that is going to be mutable will always find its way into that type in order to deal with an API which WILL use string as its arguments, not writing out "const (char) []". It gives me no information about the future of the object while removing the apparent need for the gentleman's agreement. Therefore I have no way of knowing what the actual pedigree of this string I've been given has. It may be invariant, it may be mutable.

I want this to be addressed directly. Exactly how am I wrong on this point? Is it not conceivable that mutable data gets casted to invariant in this case?