dmd 2.029 release

[grauzone]

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.)

There were a lot of posts in this thread. From what I've gathered, what 
you said wasn't really concrete. Not as concrete as the sink proposals.

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

At some point, you need to format it to a string anyway. And it's 
probably not favorable to move that code into some deeply buried library 
code, because then you don't have full control over formatting. Anyway, 
I don't quite understand what you want to do. We were talking abou 
improving toString, right?

>> One thing that I could imagine that put() automatically takes care of 
>> formatting various data types into a string. Okay, where can I pass 
>> format specifiers? What if put() can't deal with the type? Or does it 
>> call std.string.format() anyway? Then why the indirection through the 
>> string? Why not call format() directly? (Yes, format() needs to be 
>> able to output using a sink instead of returning a string.)
> 
> I'd spend more time on explaining that but I fear you want more to 
> convince yourself and others that output streams are no good and that 
> your non-design is simpler, than actually getting answers to your 
> questions.

It's not my design, and I didn't even come up with that proposal. Come 
on, I know my tone and my posts is bitchy as hell, but flaming is not 
really what I'm up to.

>> Oh by the way, unlike a weird template, sink works with virtual 
>> methods, too.
>>
>> I have the impression Andrei wants to cast everything into ranges 
>> instead of adhering to KISS.
> 
> I want to adhere to KISS, and therefore I want to support output ranges 
> with e.g. strings and files. If you don't take the time to look at 
> ranges as you yourself said, then why do you spend time commenting on 
> them? Shouldn't things go the other way?

Oh, I look at the Phobos docs as it seems necessary. But I still might 
not know to the fullest how the pieces fit together and so on.

> 
> Andrei