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

[Jason House]

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.

invariant(char[]) is not rebindable. There are bugs in bugzilla that show holes in the usage of invariant(char)[] instead of a rebindable invariant(char[]).