IMHO array literals should be static arrays, which are value types. No
issues with heap allocation or immutability requirements.
Also, even immutable values can change at runtime:
void foo(immutable int x) {
auto array = [x];
}
array would have needed to be heap allocated even if they are changed to
be immutable.
Don wrote:
(2) Concurrency issues make (1) even more important. It ought to
possible to pass an array (defined at compile time) as a message.
This sounds very special. Any example where you'd pass an array known at
compile time as message?
(3) Performance of the existing array 'literals' is absolutely
appalling. I doubled the speed of my entire app by changing ONE array
declaration from 'immutable [] xxx' into 'static const [] xxx'!!!
Right now, if an array literal appears in your code, chances are it's a
performance bug. It's deceptive that there's a hidden heap allocation
happening in every array literal. It's got no business being in a
systems language IMHO.
Delegates also can have hidden allocation (basically, you have to guess
the compiler's guess whether a delegate is a real closure). There are
several language elements that may or may not trigger additional memory
allocations (like setting .length or the ~= operator).
And the underlying problem is the bad GC that is torturing us all, isn't it?
