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