www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Array literals?

reply Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:
Is there any way to create arrays easily, using array literals?

--- test.d ---

void f(int[3] a)
{
}

void g(int x)
{
    f([1, 2, 3]); // does not work

    // Does not work either: variable tmp is not static and cannot have
    // a static initializer
    int[3] tmp = [1, 2, 3];
    f(tmp);

    // Works
    const int[3] tmp2 = [1, 2, 3];
    f(tmp2);

    const int[3] tmp3 = [x, 2, 3];
    f(tmp3);
    // Doesn't work either: non-constant expression x

    // Consequently, I have to do this:
    const int[3] tmp4;
    tmp4[0] = x; tmp4[1] = 2; tmp4[2] = 3;
    f(tmp4);

    return 0;
}

-------------

I didn't find any mention of array literals in the documentation. Maybe
they were hidden. In any case, I'd find them tremendously useful, even
more useful than function literals although the basic idea is pretty
much the same.

-Antti

-- 
I will not be using Plan 9 in the creation of weapons of mass destruction
to be used by nations other than the US.
Jun 13 2004
next sibling parent "The Dr ... who?" <thedr who.com> writes:
"Antti Sykäri" <jsykari gamma.hut.fi> wrote in message
news:slrnccp3am.hth.jsykari pulu.hut.fi...
 Is there any way to create arrays easily, using array literals?

 --- test.d ---

 void f(int[3] a)
 {
 }

 void g(int x)
 {
     f([1, 2, 3]); // does not work

     // Does not work either: variable tmp is not static and cannot have
     // a static initializer
     int[3] tmp = [1, 2, 3];
     f(tmp);

     // Works
     const int[3] tmp2 = [1, 2, 3];
     f(tmp2);

     const int[3] tmp3 = [x, 2, 3];
     f(tmp3);
     // Doesn't work either: non-constant expression x

     // Consequently, I have to do this:
     const int[3] tmp4;
     tmp4[0] = x; tmp4[1] = 2; tmp4[2] = 3;
     f(tmp4);

     return 0;
 }

 -------------

 I didn't find any mention of array literals in the documentation. Maybe
 they were hidden. In any case, I'd find them tremendously useful, even
 more useful than function literals although the basic idea is pretty
 much the same.

Count my vote! -- The Dr. da-da-da-dum, da-da-da-dum, da-da-da-dum, daaah da-da-da-dum, da-da-da-dum, da-da-da-dum, daaah woo-ooooo
Jun 13 2004
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
The fundamental problem with array literals is the bottom-up nature of the
typing of expressions in the semantic phase of compilation. Is [0,1,2,3] an
array of chars, bytes, ints, longs, floats, ... ?

This is not an easy problem to solve, which is why it'll be deferred to a
2.0 feature.
Jun 13 2004
next sibling parent reply Derek <derek psyc.ward> writes:
On Sun, 13 Jun 2004 15:35:04 -0700, Walter wrote:

 The fundamental problem with array literals is the bottom-up nature of the
 typing of expressions in the semantic phase of compilation. Is [0,1,2,3] an
 array of chars, bytes, ints, longs, floats, ... ?
 
 This is not an easy problem to solve, which is why it'll be deferred to a
 2.0 feature.

char[4] A = [0,1,2,3]; // chars byte[4] A = [0,1,2,3]; // bytes int[4] A = [0,1,2,3]; // ints long[4] A = [0,1,2,3]; // longs float[4] A = [0,1,2,3]; // floats What don't I understand about this 'difficult problem'? -- Derek Melbourne, Australia
Jun 13 2004
next sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Derek" <derek psyc.ward> wrote in message
news:b5s688p7pf1y.z5e0b4ez9omj.dlg 40tude.net...
 On Sun, 13 Jun 2004 15:35:04 -0700, Walter wrote:

 The fundamental problem with array literals is the bottom-up nature of the
 typing of expressions in the semantic phase of compilation. Is [0,1,2,3] an
 array of chars, bytes, ints, longs, floats, ... ?

 This is not an easy problem to solve, which is why it'll be deferred to a
 2.0 feature.

char[4] A = [0,1,2,3]; // chars byte[4] A = [0,1,2,3]; // bytes int[4] A = [0,1,2,3]; // ints long[4] A = [0,1,2,3]; // longs float[4] A = [0,1,2,3]; // floats What don't I understand about this 'difficult problem'?

An array literal is one that is defined in situ, and not a variable. All the above are normal arrays. An array literal would look like: void somefunc(int[] ar); int main() { int[] na = . . . ; // A normal array somefunc(na); // Passing the normal array somefunc([0, 1, 2, 3]); // Passing an array literal, defined just here! return 0; } :)
Jun 13 2004
parent reply Derek <derek psyc.ward> writes:
On Mon, 14 Jun 2004 09:09:40 +1000, Matthew wrote:

 "Derek" <derek psyc.ward> wrote in message
 news:b5s688p7pf1y.z5e0b4ez9omj.dlg 40tude.net...
 On Sun, 13 Jun 2004 15:35:04 -0700, Walter wrote:

 The fundamental problem with array literals is the bottom-up nature of the
 typing of expressions in the semantic phase of compilation. Is [0,1,2,3] an
 array of chars, bytes, ints, longs, floats, ... ?

 This is not an easy problem to solve, which is why it'll be deferred to a
 2.0 feature.

char[4] A = [0,1,2,3]; // chars byte[4] A = [0,1,2,3]; // bytes int[4] A = [0,1,2,3]; // ints long[4] A = [0,1,2,3]; // longs float[4] A = [0,1,2,3]; // floats What don't I understand about this 'difficult problem'?

An array literal is one that is defined in situ, and not a variable. All the above are normal arrays. An array literal would look like: void somefunc(int[] ar); int main() { int[] na = . . . ; // A normal array somefunc(na); // Passing the normal array somefunc([0, 1, 2, 3]); // Passing an array literal, defined just here! return 0; } :)

Ok, I didn't make my self clear yet again. In my examples, I was trying to demostrate that the compiler had enough information to work out what the array literals were meant to be. The info comes from the datatype the array literals was being assigned to. In your example, the compiler still has enough info. If 'somefunc' requires that an 'int[]' be passed to it, then the array literal needs also to be one of ints. As an array literal (or any literal for that matter) does not exist outside of some context, it should be able to determine its datatype *in* that context. We don't have problems with numeric literals. void anotherfunc(float a); . . . anotherfunc(4); // '4' is a float, no? -- Derek Melbourne, Australia
Jun 13 2004
next sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Derek" <derek psyc.ward> wrote in message
news:1ovbt2dsuadke.1hsc4hq8954kj$.dlg 40tude.net...
 On Mon, 14 Jun 2004 09:09:40 +1000, Matthew wrote:

 "Derek" <derek psyc.ward> wrote in message
 news:b5s688p7pf1y.z5e0b4ez9omj.dlg 40tude.net...
 On Sun, 13 Jun 2004 15:35:04 -0700, Walter wrote:

 The fundamental problem with array literals is the bottom-up nature of the
 typing of expressions in the semantic phase of compilation. Is [0,1,2,3] an
 array of chars, bytes, ints, longs, floats, ... ?

 This is not an easy problem to solve, which is why it'll be deferred to a
 2.0 feature.

char[4] A = [0,1,2,3]; // chars byte[4] A = [0,1,2,3]; // bytes int[4] A = [0,1,2,3]; // ints long[4] A = [0,1,2,3]; // longs float[4] A = [0,1,2,3]; // floats What don't I understand about this 'difficult problem'?

An array literal is one that is defined in situ, and not a variable. All the above are normal arrays. An array literal would look like: void somefunc(int[] ar); int main() { int[] na = . . . ; // A normal array somefunc(na); // Passing the normal array somefunc([0, 1, 2, 3]); // Passing an array literal, defined just here! return 0; } :)

Ok, I didn't make my self clear yet again. In my examples, I was trying to demostrate that the compiler had enough information to work out what the array literals were meant to be. The info comes from the datatype the array literals was being assigned to. In your example, the compiler still has enough info. If 'somefunc' requires that an 'int[]' be passed to it, then the array literal needs also to be one of ints. As an array literal (or any literal for that matter) does not exist outside of some context, it should be able to determine its datatype *in* that context. We don't have problems with numeric literals. void anotherfunc(float a); . . . anotherfunc(4); // '4' is a float, no?

Polymorphism and implicit conversions would scupper this, then, I think.
Jun 13 2004
parent Derek <derek psyc.ward> writes:
On Mon, 14 Jun 2004 09:43:06 +1000, Matthew wrote:

 "Derek" <derek psyc.ward> wrote in message
 news:1ovbt2dsuadke.1hsc4hq8954kj$.dlg 40tude.net...
 On Mon, 14 Jun 2004 09:09:40 +1000, Matthew wrote:

 "Derek" <derek psyc.ward> wrote in message
 news:b5s688p7pf1y.z5e0b4ez9omj.dlg 40tude.net...
 On Sun, 13 Jun 2004 15:35:04 -0700, Walter wrote:

 The fundamental problem with array literals is the bottom-up nature of the
 typing of expressions in the semantic phase of compilation. Is [0,1,2,3] an
 array of chars, bytes, ints, longs, floats, ... ?

 This is not an easy problem to solve, which is why it'll be deferred to a
 2.0 feature.

char[4] A = [0,1,2,3]; // chars byte[4] A = [0,1,2,3]; // bytes int[4] A = [0,1,2,3]; // ints long[4] A = [0,1,2,3]; // longs float[4] A = [0,1,2,3]; // floats What don't I understand about this 'difficult problem'?

An array literal is one that is defined in situ, and not a variable. All the above are normal arrays. An array literal would look like: void somefunc(int[] ar); int main() { int[] na = . . . ; // A normal array somefunc(na); // Passing the normal array somefunc([0, 1, 2, 3]); // Passing an array literal, defined just here! return 0; } :)

Ok, I didn't make my self clear yet again. In my examples, I was trying to demostrate that the compiler had enough information to work out what the array literals were meant to be. The info comes from the datatype the array literals was being assigned to. In your example, the compiler still has enough info. If 'somefunc' requires that an 'int[]' be passed to it, then the array literal needs also to be one of ints. As an array literal (or any literal for that matter) does not exist outside of some context, it should be able to determine its datatype *in* that context. We don't have problems with numeric literals. void anotherfunc(float a); . . . anotherfunc(4); // '4' is a float, no?

Polymorphism and implicit conversions would scupper this, then, I think.

Yep, that'd do it. -- Derek Melbourne, Australia
Jun 13 2004
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Derek" <derek psyc.ward> wrote in message
news:1ovbt2dsuadke.1hsc4hq8954kj$.dlg 40tude.net...
 The fundamental problem with array literals is the bottom-up nature of




 typing of expressions in the semantic phase of compilation. Is




 array of chars, bytes, ints, longs, floats, ... ?

 This is not an easy problem to solve, which is why it'll be deferred




 2.0 feature.

char[4] A = [0,1,2,3]; // chars byte[4] A = [0,1,2,3]; // bytes int[4] A = [0,1,2,3]; // ints long[4] A = [0,1,2,3]; // longs float[4] A = [0,1,2,3]; // floats What don't I understand about this 'difficult problem'?



In the case of an initializer, there is no expression on the right hand side. It's known that it MUST be an array initializer of the array type of the variable.
 In my examples, I was trying to demostrate that the compiler had enough
 information to work out what the array literals were meant to be. The info
 comes from the datatype the array literals was being assigned to.

Consider: void foo(int[]); void foo(uint[]); void bar(int, ...); and: foo([1,2,3]); which foo is called? bar(i, [1,3,4]); what type of array is passed?
 In your example, the compiler still has enough info. If 'somefunc'

 that an 'int[]' be passed to it, then the array literal needs also to be
 one of ints.

 As an array literal (or any literal for that matter) does not exist

 of some context, it should be able to determine its datatype *in* that
 context. We don't have problems with numeric literals.

   void anotherfunc(float a);
   . . .

   anotherfunc(4);  // '4' is a float, no?

No, '4' is an int. It gets implicitly converted to a float by matching it against the argument of anotherfunc. Importantly, the types are determined *before* overload function matching is done, otherwise it could never figure out which function to call.
Jun 13 2004
next sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Walter wrote:
  void anotherfunc(float a);
  . . .

  anotherfunc(4);  // '4' is a float, no?

No, '4' is an int. It gets implicitly converted to a float by matching it against the argument of anotherfunc. Importantly, the types are determined *before* overload function matching is done, otherwise it could never figure out which function to call.

How about these rules: 1) Initially, all values in the array are assigned their types using the same rules as ordinary constants. So the array literal [1,1.0,1] starts with the types [int,float,int] 2) The various values are implicitly converted to the least complex common type. In the example above, the values are converted to [float,float,float] 3) Once all of the values have the same type, the type of the array is known: float[3] 4) If the array constant is assigned to some other array, then array types are automatically converted up, just like the values would have individually: double[] var = [1,1.0,1]; The float[3] array constant is converted up to double[3]. 5) The process proceeds recursively for multidimensional arrays: [[1,1.0,1],[2,3,4],[5,6,7]] [[int,float,int],[int,int,int],[int,int,int]] [[float,float,float],int[3],int[3]] [float[3],int[3],int[3]] [float[3],float[3],float[3]] float[3][3]
Jun 13 2004
next sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
Sounds clever, to be sure, but I fear it'd be a source of huge hidden bugs.
Imagine the horror that could spawn from a simple typo involving "." rather than
","

I agree with later posters that we need the type in there somewhere, and I don't
doubt that one of you erudite folks, or big-W himself, can concoct an elegant
and
unambiguous syntax.



-- 
The Dr.

da-da-da-dum, da-da-da-dum, da-da-da-dum, daaah
da-da-da-dum, da-da-da-dum, da-da-da-dum, daaah
woo-ooooo




"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:cajf6k$2mg9$1 digitaldaemon.com...
 Walter wrote:
  void anotherfunc(float a);
  . . .

  anotherfunc(4);  // '4' is a float, no?

No, '4' is an int. It gets implicitly converted to a float by matching it against the argument of anotherfunc. Importantly, the types are determined *before* overload function matching is done, otherwise it could never figure out which function to call.

How about these rules: 1) Initially, all values in the array are assigned their types using the same rules as ordinary constants. So the array literal [1,1.0,1] starts with the types [int,float,int] 2) The various values are implicitly converted to the least complex common type. In the example above, the values are converted to [float,float,float] 3) Once all of the values have the same type, the type of the array is known: float[3] 4) If the array constant is assigned to some other array, then array types are automatically converted up, just like the values would have individually: double[] var = [1,1.0,1]; The float[3] array constant is converted up to double[3]. 5) The process proceeds recursively for multidimensional arrays: [[1,1.0,1],[2,3,4],[5,6,7]] [[int,float,int],[int,int,int],[int,int,int]] [[float,float,float],int[3],int[3]] [float[3],int[3],int[3]] [float[3],float[3],float[3]] float[3][3]

Jun 13 2004
next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:cajh6n$2pdn$1 digitaldaemon.com...
 Sounds clever, to be sure, but I fear it'd be a source of huge hidden

 Imagine the horror that could spawn from a simple typo involving "."

 ","

I agree. I'd rather have a simple and easy to understand rule that is perhaps a bit klunky rather than a complex, powerful rule that few understand (like C++ overloading rules <g>). It's also important, in language design, to have a bit of redundancy in the syntax. Redundancy is what makes it possible for a compiler to detect errors and issue a semi-comprehensible error message. If a language had no redundancy, then every random string of bytes is a valid program. (One of the reasons for the legendary obtuseness of the error messages generated by misusing C++ templates is the lack of redundancy in the syntax.) The D cast syntax is an example of improved redundancy over C's cast.
Jun 14 2004
next sibling parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
 The D cast syntax is an example of improved redundancy over C's cast.

Indeed. :)
Jun 14 2004
prev sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Walter wrote:
 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
 news:cajh6n$2pdn$1 digitaldaemon.com...
 
Sounds clever, to be sure, but I fear it'd be a source of huge hidden

bugs.
Imagine the horror that could spawn from a simple typo involving "."

rather than
","

I agree. I'd rather have a simple and easy to understand rule that is perhaps a bit klunky rather than a complex, powerful rule that few understand (like C++ overloading rules <g>).

Please interpret me as quizzical, not flaming here: I don't understand what's confusing about what I proposed. It seemed really straightforward. I'm willing to accept it if people find it confusing, but I would like if people could explain why...
 It's also important, in language design, to have a bit of redundancy in the
 syntax. Redundancy is what makes it possible for a compiler to detect errors
 and issue a semi-comprehensible error message. If a language had no
 redundancy, then every random string of bytes is a valid program.

Good point. I'm sort of liking the suggestions that are something like float[] [ 1, 2.3, 4 ] both because a) They are non-ambiguous b) They look a lot like delegate literals. :)
Jun 14 2004
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Russ Lewis wrote:
<snip>
 Good point.  I'm sort of liking the suggestions that are something like
     float[] [ 1, 2.3, 4 ]
 both because
 a) They are non-ambiguous

Which particular suggestions that are something like that are you referring to here? As said before, that one would certainly see confusion with an array of length [1, 2.3, 4] of arrays of floats. The DMD 0.92 change from [ Expression ] to [ AssignExpression ] is no solution, since one-element arrays are perfectly valid. Also, the comma-delimited list here'll mean something new when/if Norbert's MDAs are implemented. Stewart. -- My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment. Please keep replies on the 'group where everyone may benefit.
Jun 15 2004
prev sibling parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Matthew wrote:
 Sounds clever, to be sure, but I fear it'd be a source of huge hidden bugs.
 Imagine the horror that could spawn from a simple typo involving "." rather
than
 ","

When I first read this post, I totally agreed with you that this was a problem. Then I remembered that the exact same problem exists with array initializers: float[] foo = [ 1,2 , 3.4 ]; // oops, meant [ 1.2 , 3.4 ] So I would argue that if it's good enough for initializers then it's probably good enough for literals :)
Jun 14 2004
prev sibling parent Norbert Nemec <Norbert.Nemec gmx.de> writes:
Sounds a bit complicated to me, too. How about the safer alternative:

* In an array literal, all the elements have to have the same type without
any implicit conversions. Mixing types is an error.

* Afterwards, there implicit conversion happens on array type in the same
way as it happens for simple types:
        int[3] is implicitely converted to real[3] etc.

For multidimensional array literals, it is just the same: All the elements
have to have the same type (and dimension) if you put them into a higher
dimensional array literal.




Russ Lewis wrote:

 Walter wrote:
  void anotherfunc(float a);
  . . .

  anotherfunc(4);  // '4' is a float, no?

No, '4' is an int. It gets implicitly converted to a float by matching it against the argument of anotherfunc. Importantly, the types are determined *before* overload function matching is done, otherwise it could never figure out which function to call.

How about these rules: 1) Initially, all values in the array are assigned their types using the same rules as ordinary constants. So the array literal [1,1.0,1] starts with the types [int,float,int] 2) The various values are implicitly converted to the least complex common type. In the example above, the values are converted to [float,float,float] 3) Once all of the values have the same type, the type of the array is known: float[3] 4) If the array constant is assigned to some other array, then array types are automatically converted up, just like the values would have individually: double[] var = [1,1.0,1]; The float[3] array constant is converted up to double[3]. 5) The process proceeds recursively for multidimensional arrays: [[1,1.0,1],[2,3,4],[5,6,7]] [[int,float,int],[int,int,int],[int,int,int]] [[float,float,float],int[3],int[3]] [float[3],int[3],int[3]] [float[3],float[3],float[3]] float[3][3]

Jun 14 2004
prev sibling parent Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:
In article <caj05a$1r29$1 digitaldaemon.com>, Walter wrote:
 Consider:
     void foo(int[]);
     void foo(uint[]);
     void bar(int, ...);
 and:
     foo([1,2,3]);
 which foo is called?
     bar(i, [1,3,4]);
 what type of array is passed?

The same issue exists with: void foo(int); void foo(uint); void var(int, ...); foo(1); foo(i, 1); I'd really have arrays behave the same way as other basic types do.
   anotherfunc(4);  // '4' is a float, no?

No, '4' is an int. It gets implicitly converted to a float by matching it against the argument of anotherfunc. Importantly, the types are determined *before* overload function matching is done, otherwise it could never figure out which function to call.

So, similar rules are needed for arrays as now exist for arithmetic types. There probably needs to be a rule or two if there are multiple types inside an array literal: [1, 2, 3]; // array of int [1u, 2, 3]; // array of uint [1, 2, 3.0]; // array of double [1, 2.0f, 3.0]; // array of double There's just the issue of deciding a proper type that all members can be promoted to. Array literals and arrays should be castable: float[] fs; int[] is; fs[] = is; // cast each member - at least you should be able to do this // because you can do: static float[] f2 = [1,2,3]; So, any issues in this line of thought? (I'd guess plenty, but currently none comes to mind) -Antti -- I will not be using Plan 9 in the creation of weapons of mass destruction to be used by nations other than the US.
Jun 14 2004
prev sibling parent reply Matthias Becker <Matthias_member pathlink.com> writes:
 The fundamental problem with array literals is the bottom-up nature of the
 typing of expressions in the semantic phase of compilation. Is [0,1,2,3] an
 array of chars, bytes, ints, longs, floats, ... ?
 
 This is not an easy problem to solve, which is why it'll be deferred to a
 2.0 feature.

char[4] A = [0,1,2,3]; // chars byte[4] A = [0,1,2,3]; // bytes int[4] A = [0,1,2,3]; // ints long[4] A = [0,1,2,3]; // longs float[4] A = [0,1,2,3]; // floats What don't I understand about this 'difficult problem'?

typeof([0,1,2,3]) foo = [0,1,2,3]; foo is of type ...????
Jul 12 2004
next sibling parent "C. Sauls" <ibisbasenji yahoo.com> writes:
Matthias Becker wrote:
 typeof([0,1,2,3]) foo = [0,1,2,3];
 
 foo is of type ...????

In my little world, foo in that case would be of type byte, as that's the largest type neccessary to store all the values and to which all the values are compatable. If, say, 2 were 2.15, then it would be an array of floats, for the same reasons. Or maybe it could be an array of ints, with int simply being default unless uint, long, or ulong is required. Ah heck, I think I prefer the [type: x,y,z...] format. -Chris S. -Invironz
Jul 12 2004
prev sibling parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Matthias Becker wrote:
 typeof([0,1,2,3]) foo = [0,1,2,3];
 
 foo is of type ...????

This is a sticky problem, but one that I assume is already more or less solved. What happens when you do this, very similar code: ? typeof(0) bar = 0;
Jul 12 2004
prev sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
Why not require some kind of syntactic hint, as in:

    func([cast(int)0, 1, 2, 3]);

or
    func([int: 0, 1, 2, 3]);

or

    func((int[])[0, 1, 2, 3]);

or

    func(int[0, 1, 2, 3]);

?

"Walter" <newshound digitalmars.com> wrote in message
news:caikv2$1bsi$1 digitaldaemon.com...
 The fundamental problem with array literals is the bottom-up nature of the
 typing of expressions in the semantic phase of compilation. Is [0,1,2,3] an
 array of chars, bytes, ints, longs, floats, ... ?

 This is not an easy problem to solve, which is why it'll be deferred to a
 2.0 feature.

Jun 13 2004
next sibling parent reply "Vathix" <vathixSpamFix dprogramming.com> writes:
     func(int[0, 1, 2, 3]);

This one looks pretty cool.
Jun 13 2004
next sibling parent Regan Heath <regan netwin.co.nz> writes:
On Sun, 13 Jun 2004 19:12:57 -0400, Vathix 
<vathixSpamFix dprogramming.com> wrote:
     func(int[0, 1, 2, 3]);

This one looks pretty cool.

Yep. That's my favourite too. Regan. -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 13 2004
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Vathix" <vathixSpamFix dprogramming.com> wrote in message
news:cain1m$1eit$1 digitaldaemon.com...
     func(int[0, 1, 2, 3]);

This one looks pretty cool.

It's also ambiguous: foo[0,1,2,3] is this an array of foo's, or is foo an array indexed by [0,1,2,3]?
Jun 13 2004
next sibling parent reply Regan Heath <regan netwin.co.nz> writes:
On Sun, 13 Jun 2004 18:43:37 -0700, Walter <newshound digitalmars.com> 
wrote:
 "Vathix" <vathixSpamFix dprogramming.com> wrote in message
 news:cain1m$1eit$1 digitaldaemon.com...
     func(int[0, 1, 2, 3]);

This one looks pretty cool.

It's also ambiguous: foo[0,1,2,3] is this an array of foo's, or is foo an array indexed by [0,1,2,3]?

True, ok, how bout: func( cast(int[]) [0,1,2,3] ); ? -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 13 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opr9kb88nu5a2sq9 digitalmars.com...
 On Sun, 13 Jun 2004 18:43:37 -0700, Walter <newshound digitalmars.com>
 wrote:
 "Vathix" <vathixSpamFix dprogramming.com> wrote in message
 news:cain1m$1eit$1 digitaldaemon.com...
     func(int[0, 1, 2, 3]);

This one looks pretty cool.

It's also ambiguous: foo[0,1,2,3] is this an array of foo's, or is foo an array indexed by [0,1,2,3]?

True, ok, how bout: func( cast(int[]) [0,1,2,3] ); ?

Ugly <g>.
Jun 13 2004
next sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:cajaj5$2e27$1 digitaldaemon.com...
 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opr9kb88nu5a2sq9 digitalmars.com...
 On Sun, 13 Jun 2004 18:43:37 -0700, Walter <newshound digitalmars.com>
 wrote:
 "Vathix" <vathixSpamFix dprogramming.com> wrote in message
 news:cain1m$1eit$1 digitaldaemon.com...
     func(int[0, 1, 2, 3]);

This one looks pretty cool.

It's also ambiguous: foo[0,1,2,3] is this an array of foo's, or is foo an array indexed by [0,1,2,3]?

True, ok, how bout: func( cast(int[]) [0,1,2,3] ); ?

Ugly <g>.

Not that ugly. And if it gives us array literals, it'd be well worth it. Two questions: 1. Do you have an interest in getting array literals in for 1.0, if a simple and unambiguous syntax can be determined? 2. Do you have your own ideas for such a syntax?
Jun 13 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:cajb6v$2f9b$1 digitaldaemon.com...
 1. Do you have an interest in getting array literals in for 1.0, if a

 unambiguous syntax can be determined?

I recognize the need for them, but I also want to button up the feature set for 1.0 first, because I want to turn my attention to fixing all the outstanding compiler bugs and fixing some long standing deficiencies in Phobos.
 2. Do you have your own ideas for such a syntax?

Nothing definite. There's also the related problem of struct literals.
Jun 14 2004
parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:cajj1s$2sqp$2 digitaldaemon.com...
 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
 news:cajb6v$2f9b$1 digitaldaemon.com...
 1. Do you have an interest in getting array literals in for 1.0, if a

 unambiguous syntax can be determined?

I recognize the need for them, but I also want to button up the feature set for 1.0 first, because I want to turn my attention to fixing all the outstanding compiler bugs and fixing some long standing deficiencies in Phobos.

That's fine by me. We need to agree on the set of features that will go into the book, and that's closely related to 1.0's language features, so I can wait. -- Matthew Wilson Author: "Imperfect C++", Addison-Wesley, 2004 (http://www.imperfectcplusplus.com) Contributing editor, C/C++ Users Journal (http://www.synesis.com.au/articles.html#columns) STLSoft moderator (http://www.stlsoft.org) " I fold like a cheap hooker who got hit in the stomach by a fat guy with sores on his face" -- Joey -------------------------------------------------------------------------------
Jun 14 2004
prev sibling next sibling parent reply Regan Heath <regan netwin.co.nz> writes:
On Sun, 13 Jun 2004 21:41:01 -0700, Walter <newshound digitalmars.com> 
wrote:
 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opr9kb88nu5a2sq9 digitalmars.com...
 On Sun, 13 Jun 2004 18:43:37 -0700, Walter <newshound digitalmars.com>
 wrote:
 "Vathix" <vathixSpamFix dprogramming.com> wrote in message
 news:cain1m$1eit$1 digitaldaemon.com...
     func(int[0, 1, 2, 3]);

This one looks pretty cool.

It's also ambiguous: foo[0,1,2,3] is this an array of foo's, or is foo an array indexed by [0,1,2,3]?

True, ok, how bout: func( cast(int[]) [0,1,2,3] ); ?

Ugly <g>.

True, but is it ambiguous? Regan. -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 13 2004
next sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opr9kj4wsq5a2sq9 digitalmars.com...
 On Sun, 13 Jun 2004 21:41:01 -0700, Walter <newshound digitalmars.com>
 wrote:
 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opr9kb88nu5a2sq9 digitalmars.com...
 On Sun, 13 Jun 2004 18:43:37 -0700, Walter <newshound digitalmars.com>
 wrote:
 "Vathix" <vathixSpamFix dprogramming.com> wrote in message
 news:cain1m$1eit$1 digitaldaemon.com...
     func(int[0, 1, 2, 3]);

This one looks pretty cool.

It's also ambiguous: foo[0,1,2,3] is this an array of foo's, or is foo an array indexed by [0,1,2,3]?

True, ok, how bout: func( cast(int[]) [0,1,2,3] ); ?

Ugly <g>.

True, but is it ambiguous?

Of course. It's an array of ints. In fact, you could specify other things in there, and rely on the implicit conversions, just as with any other variables.
Jun 13 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
On Mon, 14 Jun 2004 15:32:29 +1000, Matthew 
<admin stlsoft.dot.dot.dot.dot.org> wrote:
 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opr9kj4wsq5a2sq9 digitalmars.com...
 On Sun, 13 Jun 2004 21:41:01 -0700, Walter <newshound digitalmars.com>
 wrote:
 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opr9kb88nu5a2sq9 digitalmars.com...
 On Sun, 13 Jun 2004 18:43:37 -0700, Walter 


 wrote:
 "Vathix" <vathixSpamFix dprogramming.com> wrote in message
 news:cain1m$1eit$1 digitaldaemon.com...
     func(int[0, 1, 2, 3]);

This one looks pretty cool.

It's also ambiguous: foo[0,1,2,3] is this an array of foo's, or is foo an array indexed by [0,1,2,3]?

True, ok, how bout: func( cast(int[]) [0,1,2,3] ); ?

Ugly <g>.

True, but is it ambiguous?

Of course.

? if it's ambiguous then Walter cannot use this syntax for array literals. Didn't you just say: "Not that ugly. And if it gives us array literals, it'd be well worth it."
 It's an array of ints. In fact, you could specify other things in
 there, and rely on the implicit conversions, just as with any other 
 variables.

Regan -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 13 2004
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opr9kkrudn5a2sq9 digitalmars.com...
 On Mon, 14 Jun 2004 15:32:29 +1000, Matthew
 <admin stlsoft.dot.dot.dot.dot.org> wrote:
 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opr9kj4wsq5a2sq9 digitalmars.com...
 On Sun, 13 Jun 2004 21:41:01 -0700, Walter <newshound digitalmars.com>
 wrote:
 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opr9kb88nu5a2sq9 digitalmars.com...
 On Sun, 13 Jun 2004 18:43:37 -0700, Walter


 wrote:
 "Vathix" <vathixSpamFix dprogramming.com> wrote in message
 news:cain1m$1eit$1 digitaldaemon.com...
     func(int[0, 1, 2, 3]);

This one looks pretty cool.

It's also ambiguous: foo[0,1,2,3] is this an array of foo's, or is foo an array indexed by [0,1,2,3]?

True, ok, how bout: func( cast(int[]) [0,1,2,3] ); ?

Ugly <g>.

True, but is it ambiguous?

Of course.

? if it's ambiguous then Walter cannot use this syntax for array literals. Didn't you just say: "Not that ugly. And if it gives us array literals, it'd be well worth it."
 It's an array of ints. In fact, you could specify other things in
 there, and rely on the implicit conversions, just as with any other
 variables.


Sorry, I read your "True, but is it ambiguous?" as "True, but is it unambiguous?" Doh!
Jun 13 2004
parent Regan Heath <regan netwin.co.nz> writes:
On Mon, 14 Jun 2004 15:45:39 +1000, Matthew 
<admin stlsoft.dot.dot.dot.dot.org> wrote:

 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opr9kkrudn5a2sq9 digitalmars.com...
 On Mon, 14 Jun 2004 15:32:29 +1000, Matthew
 <admin stlsoft.dot.dot.dot.dot.org> wrote:
 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opr9kj4wsq5a2sq9 digitalmars.com...
 On Sun, 13 Jun 2004 21:41:01 -0700, Walter 


 wrote:
 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opr9kb88nu5a2sq9 digitalmars.com...
 On Sun, 13 Jun 2004 18:43:37 -0700, Walter


 wrote:
 "Vathix" <vathixSpamFix dprogramming.com> wrote in message
 news:cain1m$1eit$1 digitaldaemon.com...
     func(int[0, 1, 2, 3]);

This one looks pretty cool.

It's also ambiguous: foo[0,1,2,3] is this an array of foo's, or is foo an array indexed by





 True, ok, how bout:

 func( cast(int[]) [0,1,2,3] );

 ?

Ugly <g>.

True, but is it ambiguous?

Of course.

? if it's ambiguous then Walter cannot use this syntax for array literals. Didn't you just say: "Not that ugly. And if it gives us array literals, it'd be well worth it."
 It's an array of ints. In fact, you could specify other things in
 there, and rely on the implicit conversions, just as with any other
 variables.


Sorry, I read your "True, but is it ambiguous?" as "True, but is it unambiguous?" Doh!

I figured that is what happened. Regan -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 13 2004
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opr9kj4wsq5a2sq9 digitalmars.com...
 True, ok, how bout:

 func( cast(int[]) [0,1,2,3] );

 ?

Ugly <g>.

True, but is it ambiguous?

No, syntactically it would work. It's just too many (), too many [], etc., for the old eyes.
Jun 14 2004
next sibling parent Kevin Bealer <Kevin_member pathlink.com> writes:
In article <cajj1s$2sqp$3 digitaldaemon.com>, Walter says...
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opr9kj4wsq5a2sq9 digitalmars.com...
 True, ok, how bout:

 func( cast(int[]) [0,1,2,3] );

 ?

Ugly <g>.

True, but is it ambiguous?

No, syntactically it would work. It's just too many (), too many [], etc., for the old eyes.

How about: int[ int: 0, 1, 2, 3, 5, byte: 0xFF, 0x33 ] .. Which would convert to int[]. Then, for classes: Interface I { ... } class A : I { A(int x); ... } class B : A { B(int x, int y); ... } I[ A:(1), 2, 3, B:(4,0), (5,2), (6,101) ] In other words, the elements seperated by "," are initializer lists; if they are not in parens, they are single-argument versions. The "A:" indicates we are switching to type A. Concise, flexible, and scalable (it scales from primitive to complex types). And only a little ugly. Kevin
Jun 15 2004
prev sibling parent reply Matthias Becker <Matthias_member pathlink.com> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opr9kj4wsq5a2sq9 digitalmars.com...
 True, ok, how bout:

 func( cast(int[]) [0,1,2,3] );

 ?

Ugly <g>.

True, but is it ambiguous?

No, syntactically it would work. It's just too many (), too many [], etc., for the old eyes.

The [type: 0,1,2,3] variant looks cool to me. We could use something similar for struct-literals: {type: 0,1,2,3}
Jul 12 2004
parent "Vathix" <vathixSpamFix dprogramming.com> writes:
"Matthias Becker" <Matthias_member pathlink.com> wrote in message
news:ccu2q1$1p9f$1 digitaldaemon.com...
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opr9kj4wsq5a2sq9 digitalmars.com...
 True, ok, how bout:

 func( cast(int[]) [0,1,2,3] );

 ?

Ugly <g>.

True, but is it ambiguous?

No, syntactically it would work. It's just too many (), too many [],


for the old eyes.

The [type: 0,1,2,3] variant looks cool to me. We could use something

 struct-literals: {type: 0,1,2,3}

struct already has {field_name: 3} which would be ambiguous if a type could be there. Actually, using the template syntax doesn't look like it'd be a problem because of the different brackets: int![1, 2, 3] my_struct!{3} You might get all confused with something like this, though: my_template!(int,int[1])(ints[1],int![1]); I don't know ;)
Jul 12 2004
prev sibling parent reply Roberto Mariottini <Roberto_member pathlink.com> writes:
In article <cajaj5$2e27$1 digitaldaemon.com>, Walter says...
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opr9kb88nu5a2sq9 digitalmars.com...

 True, ok, how bout:

 func( cast(int[]) [0,1,2,3] );

 ?

Ugly <g>.

and: func ( int[] : [0, 1 , 2, 3] ); ? Ciao P.S.: what about ':' being accepted in type declarations: int : var1, var2; float[] : var3; int[][char] : var4; It seems clearer, and it can be optional, too.
Jun 14 2004
parent Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:
In article <cak7co$r3h$1 digitaldaemon.com>, Roberto Mariottini wrote:
 In article <cajaj5$2e27$1 digitaldaemon.com>, Walter says...
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opr9kb88nu5a2sq9 digitalmars.com...

 True, ok, how bout:

 func( cast(int[]) [0,1,2,3] );


func ( int[] : [0, 1 , 2, 3] );

func( [int: 0, 1, 2, 3] ); -Antti -- I will not be using Plan 9 in the creation of weapons of mass destruction to be used by nations other than the US.
Jul 12 2004
prev sibling parent Matthias Becker <Matthias_member pathlink.com> writes:
It's also ambiguous:

    foo[0,1,2,3]

is this an array of foo's, or is foo an array indexed by [0,1,2,3]?

To me [foo: 0,1,2,3] looks cooler anyway :)
Jul 12 2004
prev sibling parent reply "Carlos Santander B." <carlos8294 msn.com> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> escribió en el mensaje
news:caimnk$1e7l$1 digitaldaemon.com
| Why not require some kind of syntactic hint, as in:
|
|     func([cast(int)0, 1, 2, 3]);
|
| or
|     func([int: 0, 1, 2, 3]);
|
| or
|
|     func((int[])[0, 1, 2, 3]);
|
| or
|
|     func(int[0, 1, 2, 3]);
|
| ?
|

I'd prefer it as C# does it: new int[] [0,1,2,3];

-----------------------
Carlos Santander Bernal
Jun 13 2004
next sibling parent reply Sam McCall <tunah.d tunah.net> writes:
Carlos Santander B. wrote:
 I'd prefer it as C# does it: new int[] [0,1,2,3];

Sam
Jun 13 2004
parent Sam McCall <tunah.d tunah.net> writes:
Sam McCall wrote:

 Carlos Santander B. wrote:
 
 I'd prefer it as C# does it: new int[] [0,1,2,3];

Or new int[0,1,2,3]? Sam

Ignore me ;-) Sam
Jun 14 2004
prev sibling parent reply "Ivan Senji" <ivan.senji public.srce.hr> writes:
"Carlos Santander B." <carlos8294 msn.com> wrote in message
news:cairv5$1l38$1 digitaldaemon.com...
 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> escribió en el mensaje
 news:caimnk$1e7l$1 digitaldaemon.com
 | Why not require some kind of syntactic hint, as in:
 |
 |     func([cast(int)0, 1, 2, 3]);
 |
 | or
 |     func([int: 0, 1, 2, 3]);
 |
 | or
 |
 |     func((int[])[0, 1, 2, 3]);
 |
 | or
 |
 |     func(int[0, 1, 2, 3]);
 |
 | ?
 |

 I'd prefer it as C# does it: new int[] [0,1,2,3];

Or what about new int[] = [1,2,3]; new int[2,2] = [[1,2],[3,4]] ...
 -----------------------
 Carlos Santander Bernal

Jun 14 2004
next sibling parent reply Derek <derek psyc.ward> writes:
On Mon, 14 Jun 2004 13:13:47 +0200, Ivan Senji wrote:

 "Carlos Santander B." <carlos8294 msn.com> wrote in message
 news:cairv5$1l38$1 digitaldaemon.com...
 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> escribió en el mensaje
 news:caimnk$1e7l$1 digitaldaemon.com
| Why not require some kind of syntactic hint, as in:
|
|     func([cast(int)0, 1, 2, 3]);
|
| or
|     func([int: 0, 1, 2, 3]);
|
| or
|
|     func((int[])[0, 1, 2, 3]);
|
| or
|
|     func(int[0, 1, 2, 3]);
|
| ?
|

 I'd prefer it as C# does it: new int[] [0,1,2,3];

Or what about new int[] = [1,2,3]; new int[2,2] = [[1,2],[3,4]] ...

Actually, now I've thought about this a bit more, I'll stick to my usual practice of not using anonymous literals. I like to do it this way instead... private static int[] InitWhatever = [1,2,3]; . . . func(InitWhatEver); As this is a bit more self-documenting. -- Derek Melbourne, Australia
Jun 14 2004
parent reply "Ivan Senji" <ivan.senji public.srce.hr> writes:
"Derek" <derek psyc.ward> wrote in message
news:157bpfcf3qs7n.lj00f9w3ri2m$.dlg 40tude.net...
 On Mon, 14 Jun 2004 13:13:47 +0200, Ivan Senji wrote:

 "Carlos Santander B." <carlos8294 msn.com> wrote in message
 news:cairv5$1l38$1 digitaldaemon.com...
 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> escribió en el mensaje
 news:caimnk$1e7l$1 digitaldaemon.com
| Why not require some kind of syntactic hint, as in:
|
|     func([cast(int)0, 1, 2, 3]);
|
| or
|     func([int: 0, 1, 2, 3]);
|
| or
|
|     func((int[])[0, 1, 2, 3]);
|
| or
|
|     func(int[0, 1, 2, 3]);
|
| ?
|

 I'd prefer it as C# does it: new int[] [0,1,2,3];

Or what about new int[] = [1,2,3]; new int[2,2] = [[1,2],[3,4]] ...

Actually, now I've thought about this a bit more, I'll stick to my usual practice of not using anonymous literals. I like to do it this way instead... private static int[] InitWhatever = [1,2,3]; . . . func(InitWhatEver); As this is a bit more self-documenting.

Yes it is, but it is useless as it is now! You can't do something like: int[] elems = [1,2,x2-x1]; Once i had a matrix class and it worked like this: i create a static identity matrix: static int[3][3] idn = [[1,0,0],[0,1,0],[0,0,1]]; then i passed this to matrix constructor, the constructor created a copy of it, then i called a member function that changed every element i needed to change! And it is a lot of work, when i think i could (with array litterals) do this: Mat!(3) M1 = new Mat!(3)( new float[3][3]=[[1,0,0],[0,1,0],[x2-x1,y2-y1,1]] ); This way my constructor wouldn't even have to create a deep copy but just copy a reference! An the line above is much more self-documenting then what i have now: static float[3][3] idn = [[1,0,0],[0,1,0],[0,0,1]]; Mat!(3) M1 = new Mat!(3)(idn); //creates a deep copy of idn M1.set(0,2,x2-x1); //did i get the indexes right? M1.set(1,2,y2-y1);
 --
 Derek
 Melbourne, Australia

Jun 14 2004
parent Derek <derek psyc.ward> writes:
On Mon, 14 Jun 2004 14:24:05 +0200, Ivan Senji wrote:

 "Derek" <derek psyc.ward> wrote in message
 news:157bpfcf3qs7n.lj00f9w3ri2m$.dlg 40tude.net...
 On Mon, 14 Jun 2004 13:13:47 +0200, Ivan Senji wrote:

 "Carlos Santander B." <carlos8294 msn.com> wrote in message
 news:cairv5$1l38$1 digitaldaemon.com...
 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> escribió en el mensaje
 news:caimnk$1e7l$1 digitaldaemon.com
| Why not require some kind of syntactic hint, as in:
|
|     func([cast(int)0, 1, 2, 3]);
|
| or
|     func([int: 0, 1, 2, 3]);
|
| or
|
|     func((int[])[0, 1, 2, 3]);
|
| or
|
|     func(int[0, 1, 2, 3]);
|
| ?
|

 I'd prefer it as C# does it: new int[] [0,1,2,3];

Or what about new int[] = [1,2,3]; new int[2,2] = [[1,2],[3,4]] ...

Actually, now I've thought about this a bit more, I'll stick to my usual practice of not using anonymous literals. I like to do it this way instead... private static int[] InitWhatever = [1,2,3]; . . . func(InitWhatEver); As this is a bit more self-documenting.

Yes it is, but it is useless as it is now! You can't do something like: int[] elems = [1,2,x2-x1];

I'm sorry. I misunderstood. I was just thinking of literals as values that could be determined at compile-time and didn't consider run-time values. -- Derek Melbourne, Australia
Jun 14 2004
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Ivan Senji wrote:

 "Carlos Santander B." <carlos8294 msn.com> wrote in message
 news:cairv5$1l38$1 digitaldaemon.com...

 I'd prefer it as C# does it: new int[] [0,1,2,3];


Just as ambiguous: an array of length 0,1,2,3 of arrays of ints?
 Or what about
 new int[] = [1,2,3];
 new int[2,2] = [[1,2],[3,4]]
 ...

Good idea I reckon. Since IINM a NewExpression isn't a lvalue semantically, I guess it needn't be one syntactically either, IWC this syntax would fit in. Stewart. -- My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment. Please keep replies on the 'group where everyone may benefit.
Jun 14 2004