On Wed, 11 Nov 2009 04:27:45 +0300, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
Bill Baxter wrote:
2009/11/10 Andrei Alexandrescu <seewebsiteforem...@erdani.org>:
Denis Koroskin wrote:
On Wed, 11 Nov 2009 02:49:54 +0300, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
Don wrote:
Lutger wrote:
Don wrote:
...
There is a definite use for such as thing. But the existing
toString()
is much, much worse than useless. People think you can do
something
with
it, but you can't.
eg, people have asked for BigInt to support toString(). That is an
over-my-dead-body.
Since you are in the know and probably the biggest toString() hater
around: are there plans (or rejections thereof) to change
toString() before
D2 turns gold? Seems to me it could break quite some code.
I'm hoping someone will come up with a design.
Straw man:
void toString(void delegate(const(char)[]) sink, string fmt) {
// fmt holds the format string from writefln/formatln.
// call sink() to print partial results.
}
I think the best option for toString is to take an output range and
write
to it. (The sink is a simplified range.)
Andrei
It means toString() must be either a template, or accept an abstract
InputRange interface?
It should take an interface.
So yet another type in object.d?
Or require users in import something specific in every module that's
going to use toString?
--bb
I am not sure. Opinions as always are welcome.
Andrei
Some ranges may be polymorphic, so having base interface hierarchy in
Phobos would be useful anyway.
BTW, save() is already implemented and used throughout the Phobos under a
different name - opSlice (i.e. auto copy = range[]). It's a bikeshed
discussion, but why save() and not opSlice(), or even clone()?
