First the point regarding the String being const: It's not necessarily the immutability, but that the string might be literally a constant.
E.g.
s := 'Hello All World'.Remove(6, 4);
Yes, code like this is supported.
And regarding the unique types and type helpers I think the current approach is only consequential, since you want the types to be different from the base type after all. However I think one could address this by using the inheritance features of helper types (which Delphi sadly only supports for class helpers, but not record helpers, unlike FPC):
type
TMyString = type String;
TMyStringHelper = type helper(TStringHelper) for TMyString
end;
In this example the methods from TStringBuilder would then be available for TMyString variables as well. Maybe I'll implement this in FPC, as it seems a rather logical extension.
]]>Thanks for sharing.
BTW, you can circumvent the issue by writing:
writeln(string(s2).IndexOf('3'),'=2');
Not so clean, right?
And it will copy the whole string content (via _UStrFromPWCharLen) from s2 to a temporary new UnicodeString, just to run the IndexOf() method on it...
Think of a performance nightmare...
Of course, this was IMHO unfair and my point was that I have the feeling that some later decisions about the Delphi language and RTL are inadequate.
Some changes are welcome. I do no regret the introduction of generics.
But some upcoming changes about the string policy - breaking everything just because we want to align with mainstream C# or Java habits - are just non sense to me.
I really think that Embarcadero deciders like to shoot their own foot.
Or - certainly worse - or own feet!