Is all this Invarient **** er... stuff, premature optimisation?

[Me Here]

Walter Bright wrote:

> 
> > I'm disappointed that's the only point from my post worthy of reaction :(
> 
> It appeared to me to be based on the assumption that D forced all character arrays to be invariant.

Well no. It also went on to counter the idea that we're all going to  come around to your way of thinking on this in short order.
And to attempt to dispell the idea that the provision of inmutable strings, without doing the same for all the other datatypes, is going to fix anthing major.

The exact same problems you describe for character arrays, exists for int arrays and unit arrays and....hashes of every flavour. 
Fixing one, if fixing them is what this does, without also fixing all the others, just moves the goal posts (a little). 

If a piece of code needs to know that the subject of a reference (string, int array, hash, whatever), isn't going to change, 
it is (and should be) *its responsibility* to ensure that--by taking a private copy.

Burdening all code with the costs of immutability just in case someone is vulnerable to its mutation, *and* is too lazy to take a copy, 
seems like making everyne wear condoms in case someone might have sex. And doing for just one type of array when they all suffer
from the same problem, doesn't seem liely to address the problems of unwanted pregnancies.

> I agreed with Janet's proposal to create a parallel set of routines that worked on mutable strings.

Sure. Sometime soon we will have a mutable string capable library again, and then we'll see how beneficial immutable strings really are 
on the basis of how many people make use of them.

But that doesn't address the issue of the salience of the reasoning for having them in the first place. Or the costs of using them in terms of 
stack fragmentation, additional GC runs, destruction of cache coherency, etc. etc. etc.
--