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

[Unknown W. Brackets]

Let me say it a different way:

split() returns results that are, often, stored or compared.  It is not 
often that these results are concatenated to or modified.  Possibly, 
they may not be sliced (further) often either.

Such a case represents a perfect example of an array (or string) that 
need not have a greater capacity than its length.  Indeed; no property 
of the array is likely to change - its length, contents, capacity, or 
even ptr.  All are likely to remain constant until the object is deleted 
from memory.

So, it would seem to me, this return value (as a quick example) could 
easily be changed to one that fits the following:

1. Is an array of data.
2. Does not have mutable contents (data.)
3. Does not allow its length or capacity to be extended (excuse me for 
considering this mutation.)
4. Is a reference, rather than a static array.

My suggestion is that "char[]" should _be_ a StringBuilder, and "int[]" 
should _be_ an ArrayBuilder, and we should adopt a separate syntax for 
something that _isn't_ one of those.

That said, I did just browse some of my D source files - an XML 1.0 
parser/tree and a custom rfc-compliant ftp server - and nearly the only 
concatenation I use is building exception strings.  I'm a little 
surprised.  Only a couple times do I do anything a builder would be 
useful for.

One time is on XML child nodes; since I'm building a list of children, 
it is a "builder" type thing.  However, my XML tree is fully incremental 
- that means you could traverse it before all of the data has been read 
from the net.  It would not be practical for me to use a builder that 
didn't have proper read access for this case.

I really think using a "StringBuilder" class is just like the solution 
of using a "String" class.  D, in my opinion, proved the latter was not 
necessary; I hold that the former isn't either.

-[Unknown]


Robert Jacques wrote:
> On Sat, 25 Apr 2009 14:21:49 -0400, Unknown W. Brackets 
> <unknown at simplemachines.org> wrote:
>> 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.
> 
> Okay I think we're on different pages, so I'll reiterate:
>> Robert Jacques wrote:
>>>  No, immutability really applies to the element and not just the 
>>> array length.
> 
> 1) Immutability is a bad way to express 'this array doesn't change 
> length'. Consider arrays of numbers instead of characters and you'll see 
> what I mean.
> 2) A large portion of the time immutable arrays are concatenated (i.e. 
> "hello" ~ "world")
> 
>> 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]
> 
> 1) At first glance, I don't see any reason why split couldn't or 
> shouldn't, besides string[] being shorter than immutable string[].
> 2) I don't see how this is relevant to array capacities / builders.