• Antti =?iso-8859-1?Q?Syk=E4ri?= (33/33) Jun 13 2004 Is there any way to create arrays easily, using array literals?
• The Dr ... who? (8/37) Jun 13 2004 Count my vote!
• Walter (5/5) Jun 13 2004 The fundamental problem with array literals is the bottom-up nature of t...
• Derek (10/16) Jun 13 2004 char[4] A = [0,1,2,3]; // chars
• Matthew (14/27) Jun 13 2004 An array literal is one that is defined in situ, and not a variable. All...
• Derek (17/54) Jun 13 2004 Ok, I didn't make my self clear yet again.
• Matthew (3/54) Jun 13 2004 Polymorphism and implicit conversions would scupper this, then, I think.
• Derek (5/67) Jun 13 2004 Yep, that'd do it.
• Walter (23/49) Jun 13 2004 the
• Russ Lewis (25/35) Jun 13 2004 How about these rules:
• Matthew (13/48) Jun 13 2004 Sounds clever, to be sure, but I fear it'd be a source of huge hidden bu...
• Walter (15/18) Jun 14 2004 bugs.
• Matthew (1/2) Jun 14 2004 Indeed. :)
• Russ Lewis (10/31) Jun 14 2004 Please interpret me as quizzical, not flaming here:
• Stewart Gordon (16/20) Jun 15 2004
• Russ Lewis (8/11) Jun 14 2004 When I first read this post, I totally agreed with you that this was a
• Norbert Nemec (10/51) Jun 14 2004 Sounds a bit complicated to me, too. How about the safer alternative:
• Antti =?iso-8859-1?Q?Syk=E4ri?= (29/44) Jun 14 2004 The same issue exists with:
• Matthias Becker (2/14) Jul 12 2004 typeof([0,1,2,3]) foo = [0,1,2,3];
• C. Sauls (9/12) Jul 12 2004 In my little world, foo in that case would be of type byte, as that's
• Russ Lewis (4/7) Jul 12 2004 This is a sticky problem, but one that I assume is already more or less
• Matthew (11/16) Jun 13 2004 Why not require some kind of syntactic hint, as in:
• Vathix (1/2) Jun 13 2004 This one looks pretty cool.
• Regan Heath (6/8) Jun 13 2004 Yep. That's my favourite too.
• Walter (5/7) Jun 13 2004 It's also ambiguous:
• Regan Heath (7/15) Jun 13 2004 True, ok, how bout:
• Walter (3/19) Jun 13 2004 Ugly .
• Matthew (7/30) Jun 13 2004 Not that ugly. And if it gives us array literals, it'd be well worth it.
• Walter (8/11) Jun 14 2004 simple and
• Matthew (15/24) Jun 14 2004 That's fine by me. We need to agree on the set of features that will go ...
• Regan Heath (6/29) Jun 13 2004 True, but is it ambiguous?
• Matthew (4/31) Jun 13 2004 Of course. It's an array of ints. In fact, you could specify other thing...
• Regan Heath (8/43) Jun 13 2004 ? if it's ambiguous then Walter cannot use this syntax for array literal...
• Matthew (4/45) Jun 13 2004 Sorry, I read your "True, but is it ambiguous?" as "True, but is it unam...
• Regan Heath (6/59) Jun 13 2004 I figured that is what happened.
• Walter (4/12) Jun 14 2004 No, syntactically it would work. It's just too many (), too many [], etc...
• Kevin Bealer (15/28) Jun 15 2004 How about:
• Matthias Becker (2/15) Jul 12 2004 The [type: 0,1,2,3] variant looks cool to me. We could use something sim...
• Vathix (12/28) Jul 12 2004 etc.,
• Roberto Mariottini (11/19) Jun 14 2004 and:
• Antti =?iso-8859-1?Q?Syk=E4ri?= (6/15) Jul 12 2004 func( [int: 0, 1, 2, 3] );
• Matthias Becker (1/4) Jul 12 2004 To me [foo: 0,1,2,3] looks cooler anyway :)
• Carlos Santander B. (22/22) Jun 13 2004 "Matthew" escribió en el mensaje
• Sam McCall (3/4) Jun 13 2004 Or new int[0,1,2,3]?
• Sam McCall (4/10) Jun 14 2004 Oops, this would be a rectangular array, wouldn't it...
• Ivan Senji (6/28) Jun 14 2004 Or what about
• Derek (11/40) Jun 14 2004 Actually, now I've thought about this a bit more, I'll stick to my usual
• Ivan Senji (23/63) Jun 14 2004 Yes it is, but it is useless as it is now!
• Derek (6/54) Jun 14 2004 I'm sorry. I misunderstood. I was just thinking of literals as values th...
• Stewart Gordon (11/18) Jun 14 2004 Just as ambiguous: an array of length 0,1,2,3 of arrays of ints?

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.

"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

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

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

"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;
    }

:)

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

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

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

"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




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'?



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'

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?

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.

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]

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

"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

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

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.

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:

 The D cast syntax is an example of improved redundancy over C's cast.

Indeed. :)

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

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

<snip>

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.

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

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]

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.

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

"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

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;

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

"Vathix" <vathixSpamFix dprogramming.com> writes:

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

This one looks pretty cool.

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/

"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]?

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/

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

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

"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

simple and
 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.

"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

 simple and
 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

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

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/

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

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 


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

? 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/

"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


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

 ? 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!

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 


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

 ? 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/

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

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

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}

"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 [],


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}

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

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.

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.

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

"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]);
|
| ?
|



-----------------------
Carlos Santander Bernal

Sam McCall <tunah.d tunah.net> writes:

Carlos Santander B. wrote:


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

Sam McCall <tunah.d tunah.net> writes:

Sam McCall wrote:

 Carlos Santander B. wrote:
 


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

Oops, this would be a rectangular array, wouldn't it...
Ignore me ;-)
Sam

"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]);
 |
 | ?
 |



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

 -----------------------
 Carlos Santander Bernal

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]);
|
| ?
|



 
 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

"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]);
|
| ?
|



 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

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]);
|
| ?
|



 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

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

<snip>



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.