dmd 2.029 release

[Christopher Wright]

Andrei Alexandrescu wrote:
> grauzone wrote:
>> Simen Kjaeraas wrote:
>>> Do note that I might have misinterpreted it all, as Andrei's code 
>>> would not do what I have outlined above, I only feel it makes the 
>>> most sense.
>>
>> Yeah OK, but what about virtual functions? Not having it virtual is a 
>> real disadvantage, because subclass-parts aren't automatically dumped.
> 
> Streaming out is a virtual function that takes a classic interface 
> object. (I explained that in two posts.)
> 
>> What exactly is R, and why is it simpler than a Sink delegate? A Sink 
>> delegate is as simple as it gets, and what else than a string do you 
>> want to output? (Hint: this is probably not supposed to be a 
>> serialization framework.)
> 
> It is simpler than a Sink delegate because the delegate is not simple; 
> it's simplistic. You can't use std.algorithm with a delegate, it only 
> accepts one type (meaning it is very inefficient if you have multiple 
> types to output) - it's essentially a non-design.

There are two possible use cases: serializing (to a text-based or binary 
format) and formatting.

Serializing won't always fit here. For example, if you want to serialize 
to XML, you need to tell the serializer when you're beginning a tag and 
what to name it and when to end it. This might be possible with ranges, 
but it would be awkward. Or maybe you have different concerns when 
serializing in one binary format versus another. Or you're outputting 
JSON, and you could view something as an array of objects or as a single 
object -- you need to specify that.

Formatting is the other concern. This is a special case of 
non-hierarchical serialization, for which ranges could work.

However, formatting *has* to be general. I rarely need to override a 
formatting method, but I often need to access something via an interface 
or base class and format it. If this does not work, then toString is 
vastly superior. And to gain the benefits you're talking about, I have 
to be able to pass in different output streams.

You can get the first requirement by having a method that takes a 
formatting struct on Object, but then object.d depends on formatting -- 
this isn't a reasonable situation. object.d can at most define an 
interface for a formatting method:

interface OutStream { ... }
class Object
{
	...
	void print (string format, OutStream stream);
}

This is still pushing it.

An alternative is to have:
void Object.print (void delegate (...) sink);