OUString is mutable?

[Lubos Lunak]

On Wednesday 03 of October 2012, Michael Stahl wrote:
> On 03/10/12 18:19, Lubos Lunak wrote:
> >  As such, as far as I can tell, immutable OUString is only a complication
> > with no practical advantages.
>
> please read my other mail for other benefits...

 I assume you mean the mail where you refer to std.string from the D language 
and call it immutable because "cannot be mutated element-by-element", even 
though there is e.g. std.string.toUp­per­In­Place() , which clearly makes it 
mutable as far as I understand the definition of mutable. So we apparently do 
not agree on what immutable actually means after all.

 There already is OUString::operator+=, so what exactly is your definition of 
mutable if you think OUString is mutable despite this (and, moreover, why 
does that definition matter)?

 And if you think that OUString is immutable and the operator+= is some kind 
of mistake that should not be there, then what is the difference between 
operator= and operator+= given that, as far as the outside world is 
concerned, they do almost the same, except for operator+= modifying its own 
internal copy of _rtl_uString that's not accessible from outside at the time?

 I do not see any problem with OUString::operator+= that OUString::operator= 
would not already have. And since the consensus seems to be that operator= is 
needed (and indeed OUString would be awfully cumbersome without it), then 
operator+= can be there as well. And, by extension, a number of other 
modifying functions.

-- 
 Lubos Lunak
 l.lunak at suse.cz