DMD 0.167 release

[%u]

== Quote from Sean Kelly (sean at 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