www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DMD 0.167 release

reply Walter Bright <newshound digitalmars.com> writes:
Array literals, by popular demand.

http://www.digitalmars.com/d/changelog.html
Sep 18 2006
next sibling parent reply Juan Jose Comellas <jcomellas gmail.com> writes:
Thanks! Has the documentation on the digitalmars.com site been updated? I
can't find the section for array literals.


Walter Bright wrote:


 Array literals, by popular demand.
 
 http://www.digitalmars.com/d/changelog.html
Sep 18 2006
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
First of all, thank you Walter. Those look like some great features. And 
bugfixes are always good too :).


Juan Jose Comellas wrote:

 Thanks! Has the documentation on the digitalmars.com site been updated? I
 can't find the section for array literals.


Looks like it isn't updated on the site yet, but it's in the package: 
dmd/html/d/expression.html. The relevant quote:

     Array Literals

     Array literals are a comma-separated list of
     AssignExpressions between square brackets [ and ]. The
     AssignExpressions form the elements of a static array,
     the length of the array is the number of elements. The
     type of the first element is taken to be the type of all
     the elements, and all elements are implicitly converted
     to that type.

     [1,2,3];	// type is int[3], with elements 1, 2 and 3
     [1u,2,3];	// type is uint[3], with elements 1u, 2u, and 3u

One question about the above: When an array literal is used in the code, 
is the resulting array allocated on the stack?
I ask because it doesn't mention using dynamic memory allocation, nor 
does it mention the array being unusable after the scope ends...
(Since it allows AssignExpressions -- not just constants -- it can't 
generally be statically allocated, right?)
Sep 18 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Frits van Bommel wrote:

 One question about the above: When an array literal is used in the code, 
 is the resulting array allocated on the stack?
 I ask because it doesn't mention using dynamic memory allocation, nor 
 does it mention the array being unusable after the scope ends...
 (Since it allows AssignExpressions -- not just constants -- it can't 
 generally be statically allocated, right?)


It's allocated on the heap.
Sep 18 2006
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:eemulj$1ogm$1 digitaldaemon.com...

 Frits van Bommel wrote:



 It's allocated on the heap.


To expand upon this, something like

fork([1, 2, 3]);

is turned into something like

fork(_d_arrayliteral(1, 2, 3));

That is, it's a function call.  _d_arrayliteral creates a new array on the 
heap and copies its variadic arguments into it.
Sep 18 2006
prev sibling next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:eemqtr$1iaj$1 digitaldaemon.com...

 Array literals, by popular demand.

 http://www.digitalmars.com/d/changelog.html


o Added support for multidimensional array allocation with NewExpression.
o Added array literals.
o std.format will now work with struct arguments as long as they define a 
char[] toString() member function.

Three very, very tasty new features.  Thank you so much :)

And I guess you're still updating the docs.
Sep 18 2006
next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:eemsjf$1l1a$1 digitaldaemon.com...

 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:eemqtr$1iaj$1 digitaldaemon.com...

 Array literals, by popular demand.

 http://www.digitalmars.com/d/changelog.html


 o Added support for multidimensional array allocation with NewExpression.
 o Added array literals.
 o std.format will now work with struct arguments as long as they define a 
 char[] toString() member function.

 Three very, very tasty new features.  Thank you so much :)

 And I guess you're still updating the docs.


Don't know if this is a bug..

void fork(int[] x)
{
    foreach(i; x)
        writefln(i);
}

..
fork([1, 2, 3]);

That works fine.  But:

int[] x = [1, 2, 3];

Fails, since "x is not a static and cannot have static initializer."

Maybe that detection has to be removed?
Sep 18 2006
prev sibling parent Walter Bright <newshound digitalmars.com> writes:
Jarrett Billingsley wrote:

 And I guess you're still updating the docs. 


They are uploaded now.
Sep 18 2006
prev sibling next sibling parent reply clayasaurus <clayasaurus gmail.com> writes:
Walter Bright wrote:

 Array literals, by popular demand.
 
 http://www.digitalmars.com/d/changelog.html


Why isn't

int bob[] = [2,3] allowed but

int bob[]; bob = [2,3]

is allowed?
Sep 18 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
clayasaurus wrote:

 Walter Bright wrote:

 Array literals, by popular demand.

 http://www.digitalmars.com/d/changelog.html


 
 Why isn't
 
 int bob[] = [2,3] allowed but
 
 int bob[]; bob = [2,3]
 
 is allowed?


A bug? <g>
Sep 18 2006
parent reply clayasaurus <clayasaurus gmail.com> writes:
Walter Bright wrote:

 clayasaurus wrote:

 Walter Bright wrote:

 Array literals, by popular demand.

 http://www.digitalmars.com/d/changelog.html


 Why isn't

 int bob[] = [2,3] allowed but

 int bob[]; bob = [2,3]

 is allowed?


 
 A bug? <g>


Alright, is this feature supposed to work with multi-dimensional arrays 
as well? like...

bob[][] = [[2,3], [4,2], [2,0]];

I get 'invalid conversion from int[2][3] to int[][]'

Anyways I do like this feature, thanks!

~ Clay
Sep 18 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
clayasaurus wrote:

 Alright, is this feature supposed to work with multi-dimensional arrays 
 as well? like...
 
 bob[][] = [[2,3], [4,2], [2,0]];
 
 I get 'invalid conversion from int[2][3] to int[][]'


Since T[n] and T[] are different types, one gets picked. But you can do:

int[][] bob = [ cast(int[])[2,3], [4,2], [2,0] ];

as the element type of the array is determined by the type of the first 
element.
Sep 18 2006
parent reply =?iso-8859-1?q?Knud_S=F8rensen?= <12tkvvb02 sneakemail.com> writes:
On Mon, 18 Sep 2006 14:02:22 -0700, Walter Bright wrote:


 clayasaurus wrote:

 Alright, is this feature supposed to work with multi-dimensional arrays 
 as well? like...
 
 bob[][] = [[2,3], [4,2], [2,0]];
 
 I get 'invalid conversion from int[2][3] to int[][]'


 
 Since T[n] and T[] are different types, one gets picked. But you can do:
 
 int[][] bob = [ cast(int[])[2,3], [4,2], [2,0] ];
 
 as the element type of the array is determined by the type of the first 
 element.


Is it possible to let it initial number of ['s decide the dimension 

[1, -> int[]
[[2, -> int[][]
[[[3u, -> uint[][][]
etc. 

So, that we don't the ugly cast.
Sep 19 2006
parent Reiner Pope <reiner.pope REMOVE.THIS.gmail.com> writes:
Knud Sørensen wrote:

 On Mon, 18 Sep 2006 14:02:22 -0700, Walter Bright wrote:
 

 clayasaurus wrote:

 Alright, is this feature supposed to work with multi-dimensional arrays 
 as well? like...

 bob[][] = [[2,3], [4,2], [2,0]];

 I get 'invalid conversion from int[2][3] to int[][]'


 Since T[n] and T[] are different types, one gets picked. But you can do:

 int[][] bob = [ cast(int[])[2,3], [4,2], [2,0] ];

 as the element type of the array is determined by the type of the first 
 element.


 
 Is it possible to let it initial number of ['s decide the dimension 
 
 [1, -> int[]
 [[2, -> int[][]
 [[[3u, -> uint[][][]
 etc. 
 
 So, that we don't the ugly cast.


Finding the dimension is not the problem. The point is really that, 
although there is an implicit cast available from int[2] (a 
statically-sized array) to int[] (a dynamic array), there is no implicit 
cast available from int[2][3] to int[][] (multidimensional 
statically-sized and dynamic arrays, respectively). This lack of 
implicit cast is understandable, because casting in higher dimensions 
would require creation of extra temporary pointers to the arrays 
(although, on second thoughts, this conversion seems to cost no more 
than the allocation of a dynamic array anyway...)

I think that, for cases like these where casts would require, we could 
fall back on a slightly longer, yet unambiguous syntax: the syntax that 
Chris Miller suggested a few months ago:

int[]![6,7,8,9]

This would be the most verbose form, but it would mean that arrays in 
high dimensions could be declared like this:

int[][][]![ [ [1,2],[1,2] ],[ [1,2],[1,2] ] ]

instead of this:

[ cast(int[][])[ cast(int[])[1,2],[1,2] ],[ [1,2],[1,2] ] ]

which would require a cast at every dimension of the array.

Cheers,

Reiner
Sep 20 2006
prev sibling next sibling parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Walter Bright wrote:

 Array literals, by popular demand.
 
 http://www.digitalmars.com/d/changelog.html


You are a god, Walter.  :)  Once the "static initializer" catch bug is fixed, I
guess I 
can deprecate/remove Cashew's array tfunc.  Multidim new is nice as well.

One question though: I assume the answer is yes, but are multidim literals
allowed?
[[1, 2, 3], [9, 8, 7]

Assuming literal arrays resolve to variable-length arrays, I'd imagine they
would be.

-- Chris Nicholson-Sauls
Sep 18 2006
parent Walter Bright <newshound digitalmars.com> writes:
Chris Nicholson-Sauls wrote:

 One question though: I assume the answer is yes, but are multidim 
 literals allowed?
 [[1, 2, 3], [9, 8, 7]


Yes.


 Assuming literal arrays resolve to variable-length arrays, I'd imagine 
 they would be.


They resolve to fixed length arrays, which can be implicitly converted 
to variable length arrays.
Sep 18 2006
prev sibling next sibling parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Walter Bright wrote:

 Array literals, by popular demand.
 
 http://www.digitalmars.com/d/changelog.html


Okay, multidim new is still cool, but I've found that it only works if one uses
the 
parenthetical form.  In other words, this fails to compile:
foo = new int[2][3];

But this works just fine:
foo = new int[][](2, 3);

Not really a show-stopper in my opinion, but certainly lackluster.  (The
feature is still 
awesome to have, though!)

-- Chris Nicholson-Sauls
Sep 18 2006
parent Walter Bright <newshound digitalmars.com> writes:
Chris Nicholson-Sauls wrote:

 Walter Bright wrote:

 Array literals, by popular demand.

 http://www.digitalmars.com/d/changelog.html


 
 Okay, multidim new is still cool, but I've found that it only works if 
 one uses the parenthetical form.  In other words, this fails to compile:
 foo = new int[2][3];
 
 But this works just fine:
 foo = new int[][](2, 3);
 
 Not really a show-stopper in my opinion, but certainly lackluster.  (The 
 feature is still awesome to have, though!)


The reason it fails to compile is because:

	new int[2][3]

allocates a 3 element array of int[2], not int[]. Static arrays are 
different types from dynamic arrays.
Sep 18 2006
prev sibling next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter Bright wrote:

 Array literals, by popular demand.
 
 http://www.digitalmars.com/d/changelog.html




And mistyped my name again I see.

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:-  C++  a->--- UB  P+ L E  W++  N+++ o K-  w++  O? M V? PS- 
PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Sep 18 2006
parent Walter Bright <newshound digitalmars.com> writes:
Stewart Gordon wrote:

 Walter Bright wrote:

 Array literals, by popular demand.

 http://www.digitalmars.com/d/changelog.html


 

 
 And mistyped my name again I see.
 
 Stewart.


Sorry about that. Fixed.
Sep 18 2006
prev sibling next sibling parent Pragma <ericanderton yahoo.removeme.com> writes:
Walter Bright wrote:

 Array literals, by popular demand.
 
 http://www.digitalmars.com/d/changelog.html


Outstanding Walter.  Thank you.

This is certainly going to make some code out there a *lot* less clunky.

-- 
- EricAnderton at yahoo
Sep 18 2006
prev sibling next sibling parent David Medlock <noone nowhere.com> writes:
Walter Bright wrote:

 Array literals, by popular demand.
 
 http://www.digitalmars.com/d/changelog.html


Very nice Walter! Thanks as usual.

I smell one dot oh approaching!

-DavidM
Sep 18 2006
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:

 Array literals, by popular demand.
 
 http://www.digitalmars.com/d/changelog.html


Great work!  Also, I suppose it's too late to change toString to 
something more meaningful?  ie. Since D had three char types and no 
string type, it isn't exactly clear what toString will return.  Until 
this release it was possible to use something else (such as toUtf8) 
through a change to the declaration of Object, but that doesn't apply to 
structs.  So before changing my code to conform to the 'new' rule I 
thought I'd ask.


Sean
Sep 18 2006
parent %u <foo bar.com> writes:
== Quote from Sean Kelly (sean f4.ca)'s article

 Walter Bright wrote:

 Array literals, by popular demand.

 http://www.digitalmars.com/d/changelog.html


 Great work!  Also, I suppose it's too late to change toString to
 something more meaningful?  ie. Since D had three char types and no
 string type, it isn't exactly clear what toString will return.  Until
 this release it was possible to use something else (such as toUtf8)
 through a change to the declaration of Object, but that doesn't apply to
 structs.  So before changing my code to conform to the 'new' rule I
 thought I'd ask.
 Sean



Aye.

The toString() name appears to have been chosen before the whole utf issue was
worked out fully (thanks to AJ et. al.), and the name itself does not lend
itself
to supporting multiple 'string' variations since it cannot be overloaded
effectively or have the return type changed. e.g. you cannot have a

dchar toString()

Thus, the choice of toUtf8() as the default text responder/method (in object.d)
is
a better choice than toString() as it fits in nicely with toUtf16() and
toUtf32()
method names, and it correctly reflects what is actually happening -- returning
a
utf8 encoded sequence of characters.

Further, the name toString() implies a String type is returned. This is not the
case at all, since neither D nor Phobos provides a true 'String'. Arguments
about
String class aside, capturing the toString() name instead of toUtf8() tends to
inhibit the addition of a true String class at some future point.

It's not an ideal name choice and, as was noted, was chosen before all the
mutli-encoding issues were worked out.

None of this was an issue prior to dmd167 since one simply changed the method
name
in Object.d to something else instead (and adjusted elsewhere appropriately).
However, this release has a hard-coded "toString" in the compiler front-end to
support the change for structs. Thus, the noted change to object.d is no longer
as
comprehensive as before.

Please, Walter, can you avoid using a hard-coded name in the front-end? Or is
there some other way around this conflict?

I won't be able to respond on this (intermittant wifi from the back of a llama)
but I hope Sean and others can answer questions on this one?

- Kris
Sep 18 2006
prev sibling next sibling parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Mon, 18 Sep 2006 12:07:48 -0700, Walter Bright wrote:


By the way, I appreciate the new 'warning' message ...

 shadowing declaration <identifer> is deprecated

It has help me clean up some code that otherwise might have been a bit
confusing to a code reviewer.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
19/09/2006 11:06:44 AM
Sep 18 2006
parent Walter Bright <newshound digitalmars.com> writes:
Derek Parnell wrote:

 By the way, I appreciate the new 'warning' message ...
 
  shadowing declaration <identifer> is deprecated
 
 It has help me clean up some code that otherwise might have been a bit
 confusing to a code reviewer.


I like it too. It found several instances in my code of, while not 
outright bugs, definitely sloppy and confusing code.
Sep 18 2006
prev sibling next sibling parent Lionello Lunesu <lio lunesu.remove.com> writes:
Walter Bright wrote:

 Array literals, by popular demand.
 
 http://www.digitalmars.com/d/changelog.html


It's too bad the "I'm lovin' it" is already registered by MacD, it would 
have made a great slogan for D otherwise...

Thanks.

L.
Sep 18 2006
prev sibling next sibling parent Serg Kovrov <kovrov no.spam> writes:
Walter, you rocks!

It was my birthday yesterday (18.09), array literals could be considered 
as a great present. For us all. Thank you!

Could we expect AA literals next time? I'm sure there are lot of people 
waiting them, some might be lucky to get it on his birthday too =)

-- 
serg.
Sep 19 2006
prev sibling next sibling parent reply Serg Kovrov <kovrov no.spam> writes:
I believe there are some issues with array literals right now, and I am 
sure they will be fixed.

Meantime, how this array literals should be used? there is not much 
example code in docs.

int[] i = [1, 2, 3];
or
int[] i = new [1, 2, 3];
or
int[] i = new int[1, 2, 3];
Can it be used with auto i = [1, 2, 3] ?

How about array of stings?like:
char[][] s = ["one", "two", "three"];

The only syntax i managed to compile is
int[] i = new int[1, 2, 3];
but when i try to print it it produces "[0,0,0]"

Definitely a bug. But before report bugs I'd like to know how it 
actually should works.

-- 
serg.
Sep 19 2006
parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Serg Kovrov wrote:

 I believe there are some issues with array literals right now, and I am 
 sure they will be fixed.
 
 Meantime, how this array literals should be used? there is not much 
 example code in docs.
 
 int[] i = [1, 2, 3];


This is the one, except the static initializor checks have not been culled yet,
so it 
doesn't compile.  (This is a bug.)  For now, you would do something like this:

int[] i; i = [1, 2, 3];


 or
 int[] i = new [1, 2, 3];
 or
 int[] i = new int[1, 2, 3];
 Can it be used with auto i = [1, 2, 3] ?
 
 How about array of stings?like:
 char[][] s = ["one", "two", "three"];


Just like this, once the static-init-chk is culled.


 The only syntax i managed to compile is
 int[] i = new int[1, 2, 3];
 but when i try to print it it produces "[0,0,0]"
 
 Definitely a bug. But before report bugs I'd like to know how it 
 actually should works.
 


Try compiling/running the following:








-- Chris Nicholson-Sauls
Sep 19 2006
prev sibling next sibling parent Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Walter Bright wrote:

 Array literals, by popular demand.


Fantastic, thanks!
Sep 19 2006
prev sibling next sibling parent reply Don Clugston <dac nospam.com.au> writes:
Walter Bright wrote:

 Array literals, by popular demand.
 
 http://www.digitalmars.com/d/changelog.html


Cool!

But I'm a bit baffled -- have we skipped D 1.0 ?
I thought that array literals were one of the flagship features for 
D2.0! To parody:

"Is DMD 0.167   2.0 beta 1?"

Maybe 'array literal expressions' should be removed from the  'future' page?
Sep 19 2006
parent reply Kyle Furlong <kylefurlong gmail.com> writes:
Don Clugston wrote:

 Walter Bright wrote:

 Array literals, by popular demand.

 http://www.digitalmars.com/d/changelog.html


 
 Cool!
 
 But I'm a bit baffled -- have we skipped D 1.0 ?
 I thought that array literals were one of the flagship features for 
 D2.0! To parody:
 
 "Is DMD 0.167   2.0 beta 1?"
 
 Maybe 'array literal expressions' should be removed from the  'future' 
 page?


Possibly Walter found it was easier to implement than he had expected?

-- 
Kyle Furlong // Physics Undergrad, UCSB

"D is going wherever the D community wants it to go." - Walter Bright
Sep 19 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Kyle Furlong wrote:

 Possibly Walter found it was easier to implement than he had expected?


Easier to implement than arguing about it <g>.
Sep 19 2006
next sibling parent reply David Medlock <noone nowhere.com> writes:
Walter Bright wrote:


 Kyle Furlong wrote:
 

 Possibly Walter found it was easier to implement than he had expected?


 
 
 Easier to implement than arguing about it <g>.


LOL guys, we are wearing him down!
Sep 19 2006
parent Fredrik Olsson <peylow gmail.com> writes:
David Medlock skrev:

 Walter Bright wrote:
 

 Kyle Furlong wrote:


 Possibly Walter found it was easier to implement than he had expected?



 Easier to implement than arguing about it <g>.


 
 LOL guys, we are wearing him down!


So now is the time to be nagging about using properties as lvalues?

Great stuff, array literals have allowed me to cut many lines of codes 
and ugly hacks. Unfortunately I also have to wait for GDC :/. But some 
things are well worth waiting for.

// Fredrik Olsson
Sep 20 2006
prev sibling parent Kyle Furlong <kylefurlong gmail.com> writes:
Walter Bright wrote:

 Kyle Furlong wrote:

 Possibly Walter found it was easier to implement than he had expected?


 
 Easier to implement than arguing about it <g>.


Thats the spirit!

-- 
Kyle Furlong // Physics Undergrad, UCSB

"D is going wherever the D community wants it to go." - Walter Bright
Sep 20 2006
prev sibling parent Chad J <""gamerChad\" spamIsBad gmail.com"> writes:
Walter Bright wrote:

 Array literals, by popular demand.
 
 http://www.digitalmars.com/d/changelog.html


Walter, you freakin' rule!
Sep 20 2006