dmd 2.029 release

[Georg Wrede]

Don wrote:
> bearophile wrote:
>> This post is mostly for Andrei.
>> I have played with D2 a bit; probably I'll need months to digest it 
>> and its new Phobos2. While I explore Phobos I'll probably post some 
>> comments/bugs around here.
>>
>> After reading this:
>> http://blogs.msdn.com/vcblog/archive/2009/04/22/decltype-c-0x-features-in-vc10-part-3.aspx 
>>
>> I have tried to write a toy implementation of it in D2 (not using 
>> Phobos2 yet):
>>
>> import std.stdio: writeln;
>> import std.string: format;
>>
>> struct Watts {
...

>> Two things to improve:
>> 1) All structs must have a default built-in opString, a good 
>> representation can be:
>> StructName(field_value1, field_value2, field_value1, ...).
>> It's not a perfect textual representation, but it's WAY better than 
>> the current one (currently it shows just the struct name).
>> (Printing the module name before the struct name is bad, most times is 
>> just noise)
> 
> No!
> <rant>
> toString() is one of the most dreadful features in D. Trying to slightly 
> improve it is a waste of time -- the whole concept needs to be redone.
> It's horribly inflexible, tedious, and hugely inefficient. What more 
> could there be to hate?
> 
> - the object being called has no context. It doesn't know what format is 
> desired, for example.
> - you can't emulate formatting of built-in types, NOT EVEN int! You 
> can't do left-align, pad with zeros, include + sign, display in hex.
> 
> - it's got no stream concept. Every object has to create and manage its 
> own buffer, and nobody knows if anyone actually needs it.
> 
> It ought to be at least as simple as:
> 
> struct Foo(A, B, C){
> A[10] a;
> B b;
> C c;
> void toString(Sink sink){
>    foreach(x; a) sink(x);
>    sink(b);
>    sink(c);
> }
> }
> ... but it's not, you have to create a silly buffer to put all your 
> strings in, even if there are 200 million of them and your giant string 
> is just going to be written to a file anyway.
> 
> I'd like to see version(debug) {} put around Object.toString(). It's a 
> deathtrap feature that's got no business being used other than for 
> debugging.
> </rant>

First of all, printing stuff "struct.toString()" style is for two things:

  o  Debugging
  o  Small throwaway code snippets

The latter mainly being for two purposes:

  o  Testing quick concepts, trying out library functions, etc.
  o  For the newbie, when he's learning D, but not output formatting.

No "Real Program" uses this, because there you typically do proper 
formatting of the output anyway, and almost never print entire structs 
or objects as such. Instead, rather the information that they represent.



Second, since we have cool stuff in D, like templates, boxing, and other 
advanced things, then compared to them, it should not be a big deal to 
have automatic creation of toString for structs and objects. (This could 
even be on-demand, i.e. unless called, the toString is not created for 
an object/struct.)

Since the purpose of toString here is not Grand Style, it should suffice 
to just recursively print the struct with its possible substructs, etc.

This would relieve the programmer from the entire extra work, and it 
would also make objects look tidyer in source code.

Actually, this way, it would become trivial to print stuff:

myFancyStructWithInnerStructs st;
myRealCoolObject mo;
int i;
float f;
string s;

writeln(st,mo,i,f,s);

Here the programmer couldn't care less about looks and formatting, *as 
long as* the output is legible and clear.

And what luxury -- not having to update the toString function each time 
you change the class' structure! (That's a relief in the early stages of 
the program, when everything is alive and fluid, before one settles on 
the optimum structure.)

Naturally, if the programmer *does* supply a toString() method, then 
that'd be used instead.

--------

Another way to do this would be to have a template function that writeln 
(but not writefln) calls, which introspects the printee, and prints it.