www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Array literals

reply bearophile <bearophileHUGS lycos.com> writes:
By default arrays/strings in D1 are static:

import std.stdio: writefln;
void main() {
    auto a = ["Hello", "what"];
    writefln(a[2].length); // 5
}

To remove a significant amount of bugs from my code, like that one (the second
string is a static array of length 5) I suggest to "invert" the meaning of
array literals: by default they define dynamic arrays/strings allocated on the
heap (immutable too, if necessary). So a different and explicit syntax can be
used/invented to denote static arrays.

So this literal defines a dynamic array of heap-allocated strings:
auto a = ["Hello", "what"];

A possible syntax to allocate a fixed size array of (immutable) fixed size
arrays of chars:
string[auto][auto] a = ["Hello", "what"];

This goes well with the usual D philosophy of "safety".

Bye,
bearophile
Oct 15 2008
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
bearophile:

 A possible syntax to allocate a fixed size array of (immutable) fixed size
arrays of chars:
 string[auto][auto] a = ["Hello", "what"];



That was of course:
char[auto][auto] a = ["Hello", "what"];

Bye,
bearophile
Oct 15 2008
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"bearophile" wrote

 By default arrays/strings in D1 are static:

 import std.stdio: writefln;
 void main() {
    auto a = ["Hello", "what"];
    writefln(a[2].length); // 5
 }

 To remove a significant amount of bugs from my code, like that one (the 
 second string is a static array of length 5) I suggest to "invert" the 
 meaning of array literals: by default they define dynamic arrays/strings 
 allocated on the heap (immutable too, if necessary). So a different and 
 explicit syntax can be used/invented to denote static arrays.



I think this can be solved even simpler.  Make string literal type be 
invariant(char)[] instead of static array.  It does not need to be on the 
heap.  That would solve lots of IFTI problems too.

And probably no way this gets into D1...

-Steve
Oct 15 2008
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Steven Schveighoffer:

 I think this can be solved even simpler.  Make string literal type be 
 invariant(char)[] instead of static array.  It does not need to be on the 
 heap.  That would solve lots of IFTI problems too.



With your idea this syntax:
auto a = ["Hello", "what"];
Gives a fixed-sized array of invariant(char)[]. I think that's asymmetric. My
suggestion works with all arrays, so the array 'a' too becomes/is dynamic,
keeping the simmetry.

Bye,
bearophile
Oct 15 2008
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:gd63sv$2j0t$1 digitalmars.com...

 Steven Schveighoffer:

 I think this can be solved even simpler.  Make string literal type be
 invariant(char)[] instead of static array.  It does not need to be on the
 heap.  That would solve lots of IFTI problems too.



 With your idea this syntax:
 auto a = ["Hello", "what"];
 Gives a fixed-sized array of invariant(char)[]. I think that's asymmetric. 
 My suggestion works with all arrays, so the array 'a' too becomes/is 
 dynamic, keeping the simmetry.



Sure, make the type dynamic for all array literals.  My issue is with your 
proposal to make the data allocated on the heap.

There is no need for an array literal to be typed as a static array.  Ever.

-Steve
Oct 15 2008
parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Wed, 15 Oct 2008 21:12:31 -0400,
Steven Schveighoffer wrote:

 
 "bearophile" <bearophileHUGS lycos.com> wrote in message 
 news:gd63sv$2j0t$1 digitalmars.com...

 Steven Schveighoffer:

 I think this can be solved even simpler.  Make string literal type be
 invariant(char)[] instead of static array.  It does not need to be on the
 heap.  That would solve lots of IFTI problems too.



 With your idea this syntax:
 auto a = ["Hello", "what"];
 Gives a fixed-sized array of invariant(char)[]. I think that's asymmetric. 
 My suggestion works with all arrays, so the array 'a' too becomes/is 
 dynamic, keeping the simmetry.



 Sure, make the type dynamic for all array literals.  My issue is with your 
 proposal to make the data allocated on the heap.
 
 There is no need for an array literal to be typed as a static array.  Ever.



I can see one need, matrix literals:

auto blah =
[
  [ 1,  0,  0 ],
  [ 0,  0, -1 ],
  [ 0, -1,  0 ]
];

so that blah is a sequence of 9 numbers accessed accordingly, not 3 
arrays of arbitrary length each.

Well, it's probably a special case and deserves a special, safer syntax.
Oct 16 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Sergey Gromov" <snake.scaly gmail.com> wrote in message 
news:MPG.23615f5e560d4d3f989763 news.digitalmars.com...

 Wed, 15 Oct 2008 21:12:31 -0400,
 Steven Schveighoffer wrote:

 "bearophile" <bearophileHUGS lycos.com> wrote in message
 news:gd63sv$2j0t$1 digitalmars.com...

 Steven Schveighoffer:

 I think this can be solved even simpler.  Make string literal type be
 invariant(char)[] instead of static array.  It does not need to be on 
 the
 heap.  That would solve lots of IFTI problems too.



 With your idea this syntax:
 auto a = ["Hello", "what"];
 Gives a fixed-sized array of invariant(char)[]. I think that's 
 asymmetric.
 My suggestion works with all arrays, so the array 'a' too becomes/is
 dynamic, keeping the simmetry.



 Sure, make the type dynamic for all array literals.  My issue is with 
 your
 proposal to make the data allocated on the heap.

 There is no need for an array literal to be typed as a static array. 
 Ever.



 I can see one need, matrix literals:

 auto blah =
 [
  [ 1,  0,  0 ],
  [ 0,  0, -1 ],
  [ 0, -1,  0 ]
 ];

 so that blah is a sequence of 9 numbers accessed accordingly, not 3
 arrays of arbitrary length each.

 Well, it's probably a special case and deserves a special, safer syntax.



Just don't use auto:

int[3][3] blah = ...

Make it clear your intention.  A literal should follow the most common 
usage, and leave the corner cases to specific syntax.  Most people don't use 
static arrays when working with literals.  The most common usage of static 
arrays I've seen is to establish a buffer on the stack:

byte[1000] buf = void;

-Steve
Oct 16 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:

 "Sergey Gromov" <snake.scaly gmail.com> wrote in message 
 news:MPG.23615f5e560d4d3f989763 news.digitalmars.com...

 Wed, 15 Oct 2008 21:12:31 -0400,
 Steven Schveighoffer wrote:

 "bearophile" <bearophileHUGS lycos.com> wrote in message
 news:gd63sv$2j0t$1 digitalmars.com...

 Steven Schveighoffer:

 I think this can be solved even simpler.  Make string literal type be
 invariant(char)[] instead of static array.  It does not need to be on 
 the
 heap.  That would solve lots of IFTI problems too.



 auto a = ["Hello", "what"];
 Gives a fixed-sized array of invariant(char)[]. I think that's 
 asymmetric.
 My suggestion works with all arrays, so the array 'a' too becomes/is
 dynamic, keeping the simmetry.



 your
 proposal to make the data allocated on the heap.

 There is no need for an array literal to be typed as a static array. 
 Ever.




 auto blah =
 [
  [ 1,  0,  0 ],
  [ 0,  0, -1 ],
  [ 0, -1,  0 ]
 ];

 so that blah is a sequence of 9 numbers accessed accordingly, not 3
 arrays of arbitrary length each.

 Well, it's probably a special case and deserves a special, safer syntax.



 Just don't use auto:
 
 int[3][3] blah = ...
 
 Make it clear your intention.  A literal should follow the most common 
 usage, and leave the corner cases to specific syntax.  Most people don't use 
 static arrays when working with literals.  The most common usage of static 
 arrays I've seen is to establish a buffer on the stack:
 
 byte[1000] buf = void;



Walter wanted to do things that way. I wanted to implement things the 
T[auto] way. The problem with specifying size twice is that there are 
two points of maintenance. If the language can help, why not?

Andrei
Oct 16 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Andrei Alexandrescu" wrote

 Steven Schveighoffer wrote:

 "Sergey Gromov" <snake.scaly gmail.com> wrote in message 
 news:MPG.23615f5e560d4d3f989763 news.digitalmars.com...

 Wed, 15 Oct 2008 21:12:31 -0400,
 Steven Schveighoffer wrote:

 "bearophile" <bearophileHUGS lycos.com> wrote in message
 news:gd63sv$2j0t$1 digitalmars.com...

 Steven Schveighoffer:

 I think this can be solved even simpler.  Make string literal type be
 invariant(char)[] instead of static array.  It does not need to be on 
 the
 heap.  That would solve lots of IFTI problems too.



 auto a = ["Hello", "what"];
 Gives a fixed-sized array of invariant(char)[]. I think that's 
 asymmetric.
 My suggestion works with all arrays, so the array 'a' too becomes/is
 dynamic, keeping the simmetry.



 your
 proposal to make the data allocated on the heap.

 There is no need for an array literal to be typed as a static array. 
 Ever.




 auto blah =
 [
  [ 1,  0,  0 ],
  [ 0,  0, -1 ],
  [ 0, -1,  0 ]
 ];

 so that blah is a sequence of 9 numbers accessed accordingly, not 3
 arrays of arbitrary length each.

 Well, it's probably a special case and deserves a special, safer syntax.



 Just don't use auto:

 int[3][3] blah = ...

 Make it clear your intention.  A literal should follow the most common 
 usage, and leave the corner cases to specific syntax.  Most people don't 
 use static arrays when working with literals.  The most common usage of 
 static arrays I've seen is to establish a buffer on the stack:

 byte[1000] buf = void;



 Walter wanted to do things that way. I wanted to implement things the 
 T[auto] way. The problem with specifying size twice is that there are two 
 points of maintenance. If the language can help, why not?

 Andrei



Yes, good point.

What about using static, there's a keyword that screams out 'this is static' 
:)

byte[static] = [0,1,2];

or

auto[static] = [0,1,2]; // typed as int[3]

T[auto] could look like you are trying to declare an AA with the key type 
being inferred.  But of course, that's probably very rare.

Just playing around ;)  No idea if people would like that syntax, static is 
already heavily overloaded.

-Steve
Oct 16 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:

 "Andrei Alexandrescu" wrote

 Steven Schveighoffer wrote:

 "Sergey Gromov" <snake.scaly gmail.com> wrote in message 
 news:MPG.23615f5e560d4d3f989763 news.digitalmars.com...

 Wed, 15 Oct 2008 21:12:31 -0400,
 Steven Schveighoffer wrote:

 "bearophile" <bearophileHUGS lycos.com> wrote in message
 news:gd63sv$2j0t$1 digitalmars.com...

 Steven Schveighoffer:

 I think this can be solved even simpler.  Make string literal type be
 invariant(char)[] instead of static array.  It does not need to be on 
 the
 heap.  That would solve lots of IFTI problems too.



 auto a = ["Hello", "what"];
 Gives a fixed-sized array of invariant(char)[]. I think that's 
 asymmetric.
 My suggestion works with all arrays, so the array 'a' too becomes/is
 dynamic, keeping the simmetry.



 your
 proposal to make the data allocated on the heap.

 There is no need for an array literal to be typed as a static array. 
 Ever.




 auto blah =
 [
  [ 1,  0,  0 ],
  [ 0,  0, -1 ],
  [ 0, -1,  0 ]
 ];

 so that blah is a sequence of 9 numbers accessed accordingly, not 3
 arrays of arbitrary length each.

 Well, it's probably a special case and deserves a special, safer syntax.




 int[3][3] blah = ...

 Make it clear your intention.  A literal should follow the most common 
 usage, and leave the corner cases to specific syntax.  Most people don't 
 use static arrays when working with literals.  The most common usage of 
 static arrays I've seen is to establish a buffer on the stack:

 byte[1000] buf = void;



 T[auto] way. The problem with specifying size twice is that there are two 
 points of maintenance. If the language can help, why not?

 Andrei



 Yes, good point.
 
 What about using static, there's a keyword that screams out 'this is static' 
 :)
 
 byte[static] = [0,1,2];
 
 or
 
 auto[static] = [0,1,2]; // typed as int[3]
 
 T[auto] could look like you are trying to declare an AA with the key type 
 being inferred.  But of course, that's probably very rare.
 
 Just playing around ;)  No idea if people would like that syntax, static is 
 already heavily overloaded.



T[$] was also suggested.

Andrei
Oct 16 2008
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:gd7mgi$2f83$1 digitalmars.com...

 Steven Schveighoffer wrote:

 "Andrei Alexandrescu" wrote

 Steven Schveighoffer wrote:

 "Sergey Gromov" <snake.scaly gmail.com> wrote in message 
 news:MPG.23615f5e560d4d3f989763 news.digitalmars.com...

 Wed, 15 Oct 2008 21:12:31 -0400,
 Steven Schveighoffer wrote:

 "bearophile" <bearophileHUGS lycos.com> wrote in message
 news:gd63sv$2j0t$1 digitalmars.com...

 Steven Schveighoffer:

 I think this can be solved even simpler.  Make string literal type 
 be
 invariant(char)[] instead of static array.  It does not need to be 
 on the
 heap.  That would solve lots of IFTI problems too.



 auto a = ["Hello", "what"];
 Gives a fixed-sized array of invariant(char)[]. I think that's 
 asymmetric.
 My suggestion works with all arrays, so the array 'a' too becomes/is
 dynamic, keeping the simmetry.



 your
 proposal to make the data allocated on the heap.

 There is no need for an array literal to be typed as a static array. 
 Ever.




 auto blah =
 [
  [ 1,  0,  0 ],
  [ 0,  0, -1 ],
  [ 0, -1,  0 ]
 ];

 so that blah is a sequence of 9 numbers accessed accordingly, not 3
 arrays of arbitrary length each.

 Well, it's probably a special case and deserves a special, safer 
 syntax.




 int[3][3] blah = ...

 Make it clear your intention.  A literal should follow the most common 
 usage, and leave the corner cases to specific syntax.  Most people 
 don't use static arrays when working with literals.  The most common 
 usage of static arrays I've seen is to establish a buffer on the stack:

 byte[1000] buf = void;



 T[auto] way. The problem with specifying size twice is that there are 
 two points of maintenance. If the language can help, why not?

 Andrei



 Yes, good point.

 What about using static, there's a keyword that screams out 'this is 
 static' :)

 byte[static] = [0,1,2];

 or

 auto[static] = [0,1,2]; // typed as int[3]

 T[auto] could look like you are trying to declare an AA with the key type 
 being inferred.  But of course, that's probably very rare.

 Just playing around ;)  No idea if people would like that syntax, static 
 is already heavily overloaded.



 T[$] was also suggested.



I like T[static] a lot. Static might be a highly overloaded word, but the 
idea of a "static array" is already one of the firmly established overloads. 
You want a static array? Say "static". Nice :)

I thought the exact same thing about T[auto], but didn't say anything. It 
really does make me think "AA of an inferred keytype". Which might not be a 
bad feature to have, actually.

T[$] is too much meaning-overloading. A $ inside of square brackets already 
means "length". Using it in this way is completely different. Almost looks 
like a deliberate "buffer overflow"-type ;)
Oct 17 2008
prev sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2008-10-16 11:27:24 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:


 T[$] was also suggested.



That looks much better than T[auto]. Because auto usually replaces a 
type, it makes me think more of an associative array; $ being the 
length of the array, it is exactaly what I put in the brakets when I 
want a static array.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Oct 18 2008
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Seeing how very few people care of this topic I presume I'm the only one that
does such kind of bugs. So, like the the module system that has several holes,
it will not be fixed. Oh well.

Bye,
bearophile
Oct 16 2008
parent reply ore-sama <spam here.lot> writes:
bearophile Wrote:


 Seeing how very few people care of this topic I presume I'm the only one that
does such kind of bugs. So, like the the module system that has several holes,
it will not be fixed. Oh well.
Oct 16 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
ore-sama:

 http://d.puremagic.com/issues/show_bug.cgi?id=2367#c2



Yes, sorry, I was a little nervous for an unrelated thing :-)


Comment #3 From Jarrett Billingsley  2008-09-20:

Amen to dropping the fixed-sizedness of string literals.  I suppose determining
the type based on the smallest type that can represent the data without using
multibyte encodings is reasonable enough, and you're right, it fits in with the
way it works for ints.<



My complaint/proposal regards all array literals, to keep the strings more
aligned with all the other arrays. I think all array/string literals have to
define dynamic arrays by default, and static arrays if the programmer
explicitly states so, with some short and handy syntax.
I think this is 20-40 times more important than inventing a new syntax that
replaces !()

Bye,
bearophile
Oct 16 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
bearophile:

 I think this is 20-40 times more important than inventing a new syntax that
replaces !()



I find it ironic that 100+ messages are exchanged on this NG about something
that 98-99% of people has felt as not broken (the template instantiation
syntax) while real problems that I encounter often when I program (array
literals, AA literals, etc etc) seem ignored by D developers. This is the
biggest difference between an open source language, and one language like D
where the inevitably personal bias of 1-3 people guide most of the language
design.

Bye,
bearophile
Oct 16 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:

 bearophile:

 I think this is 20-40 times more important than inventing a new
 syntax that replaces !()



 I find it ironic that 100+ messages are exchanged on this NG about
 something that 98-99% of people has felt as not broken (the template
 instantiation syntax) while real problems that I encounter often when
 I program (array literals, AA literals, etc etc) seem ignored by D
 developers. This is the biggest difference between an open source
 language, and one language like D where the inevitably personal bias
 of 1-3 people guide most of the language design.



I hear you. For the languages I know that has always been the case: one 
person or small group is behind each language. Except for Ada. What 
process do you have in mind?

I agree that array literals are problematic. I'll about that in another 
thread.

Andrei
Oct 16 2008
parent bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 I hear you.



:-)



 For the languages I know that has always been the case: one 
 person or small group is behind each language. Except for Ada. What 
 process do you have in mind?



- I have seen that to design a language you have to take hundreds or thousands
of decisions. Designing languages is hard (and I am a newbie in that job).
- Every single person has quirks, idiosyncrasies, etc, this is natural and
inevitable. This for example means that everyone has several things that
he/she/shi feels as "natural" or right, but they aren't for most other people.
- A community usually gives just an average idea; this average is precious
because it allows to find what's more natural and intuitive, but once in a
while it may lack a coherent style that just 1-3 people may have. So always
following such average ideas isn't positive.
- So, while designing the feature X in a language in the most rational,
intuitive and less error-prone way you have to find a compromise between
following a coherent style, and choosing the most commonly
appreciated/understood solution.
- I have seen Walter and you trying to design or re-design a feature X, where
most people here ask to fix the feature Y (and Z) that currently is damning lot
of D programmers; while few care of feature X or how it's (re)designed. In more
than a year of presence in this forum I think your question to name the "top 5"
was one of the few and first times that trend was inverted, asking to the
community :-)
- Summing it up, I think the current way D is designed isn't the best. I think
that its developing process may enjoy listening more to what the average D user
wants now (and it seems they often ask for a fix in some of the design mistakes
of the language). Sometimes looking for a faster horse is the right thing to do
:-)



 I agree that array literals are problematic. I'll about that in another 
 thread.



- Oh, good. Maybe in some time someone will even understand why I think the
current module system of D has some holes that it may be positive to fill/fix
:-)
(I have discussed this topic twice in the past). I think Kirk McDonald is among
the few that agrees with me :-)
- I think that fixing array literals is much higher priority than "fixing"
template instantiation syntax. But on the other hand, from the last discussions
it seems that the future D2 language will have a lot of differences from the
current D2 language: in practice every 5 posts of yours I see a suggestion
(often good!!) to change something quite basic in the way D2 syntax/semantic
works :-]
- I'm sure your presence in the D community is the best thing happened to D in
the last 15 months :-) In truth I have seen people in this community that has
ideas often as good as yours regarding the future of D, but you seem more
expert.

Bye and thank you,
bearophile
Oct 16 2008
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:

 "bearophile" wrote

 By default arrays/strings in D1 are static:

 import std.stdio: writefln;
 void main() {
    auto a = ["Hello", "what"];
    writefln(a[2].length); // 5
 }

 To remove a significant amount of bugs from my code, like that one (the 
 second string is a static array of length 5) I suggest to "invert" the 
 meaning of array literals: by default they define dynamic arrays/strings 
 allocated on the heap (immutable too, if necessary). So a different and 
 explicit syntax can be used/invented to denote static arrays.



 I think this can be solved even simpler.  Make string literal type be 
 invariant(char)[] instead of static array.  It does not need to be on the 
 heap.  That would solve lots of IFTI problems too.



Yah Walter does plan to make "string literals" dynamically-sized by 
default, but fixed-sized on demand (if you specify the appropriate 
receiver type, which in turn asks the T[auto] question). In related 
news, he wants to legitimize statically-typed arrays by making them true 
value types.

Andrei
Oct 16 2008
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 Yah Walter does plan to make "string literals" dynamically-sized by 
 default, but fixed-sized on demand (if you specify the appropriate 
 receiver type, which in turn asks the T[auto] question). In related 
 news, he wants to legitimize statically-typed arrays by making them true 
 value types.



Good. But why not make all array literals dynamically-sized by default , but
fixed-sized on demand? Isn't that more symmetric (so the D programmer has to
remember less special cased rules == simpler language)?

Bye,
bearophile
Oct 16 2008
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:

 Andrei Alexandrescu:

 Yah Walter does plan to make "string literals" dynamically-sized by
  default, but fixed-sized on demand (if you specify the appropriate
  receiver type, which in turn asks the T[auto] question). In
 related news, he wants to legitimize statically-typed arrays by
 making them true value types.



 Good. But why not make all array literals dynamically-sized by
 default , but fixed-sized on demand? Isn't that more symmetric (so
 the D programmer has to remember less special cased rules == simpler
 language)?



I agree. Walter didn't like that though, but I don't remember his 
argument. I'll defer to him.

Andrei
Oct 16 2008
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
Andrei Alexandrescu wrote:

 In related 
 news, he wants to legitimize statically-typed arrays by making them true 
 value types.



Huzzah!


Sean
Oct 16 2008
prev sibling parent Chad J <gamerchad __spam.is.bad__gmail.com> writes:
Andrei Alexandrescu wrote:

 In related news, he wants to legitimize statically-typed arrays by making them
true 
 value types.



YES
YEEEEEESSSSSSSS
Oct 16 2008
prev sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Thu, 16 Oct 2008 17:40:23 +0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 Steven Schveighoffer wrote:

 "bearophile" wrote

 By default arrays/strings in D1 are static:

 import std.stdio: writefln;
 void main() {
    auto a = ["Hello", "what"];
    writefln(a[2].length); // 5
 }

 To remove a significant amount of bugs from my code, like that one  
 (the second string is a static array of length 5) I suggest to  
 "invert" the meaning of array literals: by default they define dynamic  
 arrays/strings allocated on the heap (immutable too, if necessary). So  
 a different and explicit syntax can be used/invented to denote static  
 arrays.



 invariant(char)[] instead of static array.  It does not need to be on  
 the heap.  That would solve lots of IFTI problems too.



 Yah Walter does plan to make "string literals" dynamically-sized by  
 default, but fixed-sized on demand (if you specify the appropriate  
 receiver type, which in turn asks the T[auto] question). In related  
 news, he wants to legitimize statically-typed arrays by making them true  
 value types.

 Andrei



Good news!
Oct 16 2008