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[][]'

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.

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

"# Implemented Steward Gordon's suggestions per D.bugs/3843." 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

"# Implemented Steward Gordon's suggestions per D.bugs/3843." 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

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: # import std .stdio ; # # void main () { # writefln([1, 2, 3]); # writefln(["foo", "bar"]); # } -- 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