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

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

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

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.

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.

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.

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.

Walter Bright wrote:
> Array literals, by popular demand.

Fantastic, thanks!

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?

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