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

[Unknown W. Brackets]

1. Well, I think that immutable(T[]) ~ immutable(T[]) should be 
possible.  I thought it was.  Just that you cannot _append_ to 
immutable(T[]) which completely makes sense.

2. I don't know that it rarely concatenates.  I took Calc, but I am not 
a mathematician... mostly I use char and object references in my arrays. 
  Occasionally int[], and maybe real[] but it's not likely.

So, yes, I probably am not properly addressing this.  Frankly I do not 
know the use-cases where you would mutate such an array.

For objects, if you don't change the array length, it's unlikely you'll 
change its contents (pointers.)  Unfortunately, the referenced object 
would need to be mutable in many cases (although this is probably less 
than one would think offhand for the case of arrays of 
already-initialized objects.)

3. Okay.  I think for a multi-purpose builder, that's true.  However, 
speaking only of having an extended capacity (as is currently and as I 
was quoting), and not other features of a builder, I think what I say 
does make sense.

4. I don't think so.  Again, I'm not talking about a full-fledged 
builder (although I think more features of one would be possible without 
too much difference except fake methods), just about features.

So, to recap, I'm really talking about not over-allocating immutable 
arrays, but I'm not talking about changing current arrays.  Does that 
make my comments make more sense?

-[Unknown]


Robert Jacques wrote:
> On Sat, 25 Apr 2009 20:17:00 -0400, Unknown W. Brackets 
> <unknown at simplemachines.org> wrote:
> 
>> 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]
> 
> Okay, I understand where you're coming from. Here are some counter-points
> 1) Immutable strings are often concatenated, which you don't address
> 2) int[], real[], and basically anything not a string rarely 
> concatenates, but often mutable, which you don't address
> 3) Rather large thread a while ago concluded the builder overhead was 
> too high for general use.
> 4) You're proposal makes immutable char[] and char[] have different 
> underlying representations.