If T[new] is the container for T[], then what is the container for T[U]?

[Unknown W. Brackets]

I'm not talking about invariant(char)[], I'm talking about 
invariant(char[]).  That cannot be extended in length.  Really, what I 
want is something that is a "invariant(variant(char)[])", I suppose, but 
I don't even think that's necessary.

When the default string type was made invariant, many people were 
non-plussed at best.  That doesn't mean it was wrong.

How crazy would it be if, for example, std.string.split returned 
invariant(string[]) instead of string[]?  I doubt it would hurt many 
people, in actuality, and you could always get a mutable copy.

-[Unknown]


Robert Jacques wrote:
> On Sat, 25 Apr 2009 13:30:22 -0400, Unknown W. Brackets 
> <unknown at simplemachines.org> wrote:
>> What about simply using the const/invariant information?
>>
>> After all, an "array builder" is a mutable array.  If you don't want 
>> to extend it, it should be invariant or const - e.g. invariant(string).
> 
> No, immutability really applies to the element and not just the array 
> length. Besides, what about "hello" ~ "world"? Essentially, an "array 
> builder" is an array with a cheaply, extend-able length and it's often 
> used for immutable strings, etc. Also, while a concatenate strings all 
> the time I never end up concatenating non-char arrays. And they almost 
> always end up being mutable.
> 
>> I've always thought the separation of strings and string builders, 
>> arrays and array builders, etc. was flawed.  It's just like strcmp; 
>> sure, it works, but is it really the right way to compare strings? 
>> Can't I just have my == and not worry about it?
> 
> Well, you can just use ~= or ~ and not worry about it. Array builders 
> are a performance enhancement for one special case at the cost of a 
> general performance degradation. (There was a long discussion previously 
> about these trade-offs)
> 
>