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 next 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.


 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;


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.


 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;


 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.


 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;


 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.


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.


 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;


 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.


 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.
 


http://d.puremagic.com/issues/show_bug.cgi?id=2367#c2
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 :-)




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 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 "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.


  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


Good news!
Oct 16 2008
prev sibling 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 reply bearophile <bearophileHUGS lycos.com> writes:
Nick Sabalausky:

 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 :)


+1.
I think it's acceptable. So the code equivalent to the original one becomes
(plus the immutable statement):

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

Most of the times you don't want that so you use:

auto a = ["Hello", "what"];

Now we can wait for Walter to express his opinion on this improvement of the
language.

Bye,
bearophile
Oct 17 2008
parent reply "Nick Sabalausky" <a a.a> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:gd9vqi$oos$1 digitalmars.com...

 Nick Sabalausky:

 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 :)


 +1.
 I think it's acceptable. So the code equivalent to the original one 
 becomes (plus the immutable statement):

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

 Most of the times you don't want that so you use:

 auto a = ["Hello", "what"];

 Now we can wait for Walter to express his opinion on this improvement of 
 the language.

 Bye,
 bearophile


As long as we're talking about initializing jagged static arrays, I'd also 
add one other slight change. The following should also compile (the current 
D1 equivilent code complains. Not sure about D2):

// The only change from the code above is
// swapping the order of "Hello" and "what"
import std.stdio: writefln;
void main() {
    char[static][static] a = ["what", "Hello"];
    writefln(a[1].length); // 5
}

Might just be a bug, but currently (assuming the T[static] got implemented), 
the above would fail to compile with an error complaining that it cannot 
convert "Hello" from type char[5u] to type chat[4u]. Apperently, 
"a[anything].length" is assumed to be "a[0].length" instead of 
"max(a[0].length, a[1].length,...a[$-1].length)". So, currently, a[0].length 
must be >= the longest of the rest of the strings. That's bitten me a few 
times already.
Oct 17 2008
next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2008-10-17 16:00:55 -0400, "Nick Sabalausky" <a a.a> said:


 As long as we're talking about initializing jagged static arrays, I'd also
 add one other slight change. The following should also compile (the current
 D1 equivilent code complains. Not sure about D2):
 
 // The only change from the code above is
 // swapping the order of "Hello" and "what"
 import std.stdio: writefln;
 void main() {
     char[static][static] a = ["what", "Hello"];
     writefln(a[1].length); // 5
 }
 
 Might just be a bug, but currently (assuming the T[static] got implemented),
 the above would fail to compile with an error complaining that it cannot
 convert "Hello" from type char[5u] to type chat[4u]. Apperently,
 "a[anything].length" is assumed to be "a[0].length" instead of
 "max(a[0].length, a[1].length,...a[$-1].length)". So, currently, a[0].length
 must be >= the longest of the rest of the strings. That's bitten me a few
 times already.


For that to work, you'd also need implcit conversion from T[4] to T[5]. 
How are your proposing to do that?

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Oct 18 2008
parent reply KennyTM~ <kennytm gmail.com> writes:
Michel Fortin wrote:

 On 2008-10-17 16:00:55 -0400, "Nick Sabalausky" <a a.a> said:
 

 As long as we're talking about initializing jagged static arrays, I'd 
 also
 add one other slight change. The following should also compile (the 
 current
 D1 equivilent code complains. Not sure about D2):

 // The only change from the code above is
 // swapping the order of "Hello" and "what"
 import std.stdio: writefln;
 void main() {
     char[static][static] a = ["what", "Hello"];
     writefln(a[1].length); // 5
 }

 Might just be a bug, but currently (assuming the T[static] got 
 implemented),
 the above would fail to compile with an error complaining that it cannot
 convert "Hello" from type char[5u] to type chat[4u]. Apperently,
 "a[anything].length" is assumed to be "a[0].length" instead of
 "max(a[0].length, a[1].length,...a[$-1].length)". So, currently, 
 a[0].length
 must be >= the longest of the rest of the strings. That's bitten me a few
 times already.


 
 For that to work, you'd also need implcit conversion from T[4] to T[5]. 
 How are your proposing to do that?
 


Pad with T.init
Oct 18 2008
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2008-10-18 11:31:09 -0400, KennyTM~ <kennytm gmail.com> said:


 // The only change from the code above is
 // swapping the order of "Hello" and "what"
 import std.stdio: writefln;
 void main() {
     char[static][static] a = ["what", "Hello"];
     writefln(a[1].length); // 5
 }
 
 [...]


 For that to work, you'd also need implcit conversion from T[4] to T[5]. 
 How are your proposing to do that?


 
 Pad with T.init


Should I take it then that the following assertions should hold true?

	char[static][static] a = ["what", "Hello"];
	assert(a[0] == "what\0");
	assert(a[0] != "what");

That seems completly backward.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Oct 18 2008
parent KennyTM~ <kennytm gmail.com> writes:
Michel Fortin wrote:

 On 2008-10-18 11:31:09 -0400, KennyTM~ <kennytm gmail.com> said:
 

 // The only change from the code above is
 // swapping the order of "Hello" and "what"
 import std.stdio: writefln;
 void main() {
     char[static][static] a = ["what", "Hello"];
     writefln(a[1].length); // 5
 }

 [...]


 For that to work, you'd also need implcit conversion from T[4] to 
 T[5]. How are your proposing to do that?


 Pad with T.init


 
 Should I take it then that the following assertions should hold true?
 
     char[static][static] a = ["what", "Hello"];
     assert(a[0] == "what\0");
     assert(a[0] != "what");
 
 That seems completly backward.
 


Isn't it the current behavior?

         auto x = ["World", "x"];
         writeln(typeof(x[0]).stringof);
         writeln(typeof(x[1]).stringof);
         writeln(typeof(x).stringof);
         writeln(x[1] == "x");

prints:

invariant(char[5u])
invariant(char[5u])
invariant(char[5u])[2u]
false

So at least it is just "not fixing an old bug" (if this is), but not 
"completely backward".
Oct 18 2008
prev sibling parent Sergey Gromov <snake.scaly gmail.com> writes:
Fri, 17 Oct 2008 16:00:55 -0400,
Nick Sabalausky wrote:

 "bearophile" <bearophileHUGS lycos.com> wrote in message 
 news:gd9vqi$oos$1 digitalmars.com...

 Nick Sabalausky:

 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 :)


 +1.
 I think it's acceptable. So the code equivalent to the original one 
 becomes (plus the immutable statement):

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

 Most of the times you don't want that so you use:

 auto a = ["Hello", "what"];

 Now we can wait for Walter to express his opinion on this improvement of 
 the language.

 Bye,
 bearophile


 
 As long as we're talking about initializing jagged static arrays, I'd also 
 add one other slight change. The following should also compile (the current 
 D1 equivilent code complains. Not sure about D2):
 
 // The only change from the code above is
 // swapping the order of "Hello" and "what"
 import std.stdio: writefln;
 void main() {
     char[static][static] a = ["what", "Hello"];
     writefln(a[1].length); // 5
 }


Type of an array element is inferred from the first element of a literal, 
it's in the specs.  Also, compiler probably fills the missing elements 
with default initializer so in fact you get

char[static][static] a = ["what\0", "Hello"];

or, for the same result,

char[5][static] a = ["what", "Hello"];

It'd probably be nice if, for arrays of static arrays, compiler 
automatically picked the longest inner array for the purposes of outer 
array's element type inferring.
Oct 18 2008