On 08/31/2011 10:51 AM, Don wrote:
On 31.08.2011 09:03, Jonathan M Davis wrote:
On Wednesday, August 31, 2011 08:53:29 Don wrote:
On 31.08.2011 04:41, Jonathan M Davis wrote:
On Tuesday, August 30, 2011 20:59:06 Paul D. Anderson wrote:
Can someone clarify for me the status and/or direction of string
formatting in D?
We've got:
1. toString, the object method with no parameters.
2. toString(sink, format)
3. to!String()
4. format
5. writef/writefln
6. write/writeln
I realize these exist for various reasons, some (1,3) are simple
(unformatted) conversions, others (2,4-6) are designed to provide
configurable formatting. The problem is that they are inconsistent
with
each other.
Using std.bigint as an example: 1, 3, 4 and 6 don't work, or don't
work as expected (to me at least). 1. prints 'BigInt', 3 and 4 are
compile errors.
I know bigint is a controversial example because Don has strong
feelings
against 1 and favors 2. (See bug #5231). I don't really have an
opinion one way or the other but I need to know what to implement in
my
arbitrary-precision floating point module. This obviously relies
heavily on bigint.
So, is there a transition underway in the language (or just Phobos)
from
toString, writeln and format, to toString(sink,format) and writefln?
Or is this just a divergence of views, both of which are acceptable
and
we'll have to get used to choosing one or the other?
Or am I just mistaken in believing there is any significant conflict?
I apologize if this has already been hashed out in the past and, if
so, I would appreciate someone pointing me to that discussion. (Or
just the results of the discussion.)
At this point, it's toString with no parameters. Don's completely
out in
left field with regards to how things currently work. I believe that
BigInt is the _only_ example of toString(sink, format).
Try to write BigFloat such that:
BigFloat f = 2.3e69;
writefln("%f %g", f, f);
will work. It's just not possible.
toString with no parameters does not work, and CANNOT work. It just
can't.
I implemented something quickly which actually works.
But, it's just a stop-gap measure until this black hole in the language
gets fixed. We really need the format string to be exposed in a digested
manner.
The thing is that all most people care about is converting the object
to a
string. They don't care about %d vs %x or %f vs %g. They just want it
to be
converted to a string. So, the lack of a toString is a major impediment.
That is simply not true. When you print a floating-point number, you
almost ALWAYS use a format string.
Now, I can definitely see why you would want to have toString/writeTo
work with
a format string, and I think that ultimately writeTo is probably a good
solution (though it does seem to be a bit overkill for the average
situation),
but the truth of the matter is that while your concerns are perfectly
valid,
most people wouldn't even think of the issues that you're seeing with
BigInt
or BigFloat. They just want to convert them to a string as decimal
values.
Compare with C++ iostreams. There are two fundamental features:
(1) the formatting to be used is specified;
(2) components are output piece-by-piece.
The inability to do either of these things is not a minor limitation of
string toString(). They are absolutely fundamental.
Now, once you have the full functionality, you can think about how to
simplify the common, trivial cases. But you cannot argue the other way.
(3) data can be output with standard formatting in case one does not
care. I claim that is used most of the time.
The inability to use to!string(bigint) or writeln(bigint) is not a minor
limitation either. What stops bigint from having an overload
string toString(){string r; toString((const(char)[]
x){r~=x;},"d");return r;}
that would actually work with the rest of current Phobos? The current
design has never been any more than an annoyance to me. Most generic
code that wants to work with BigInt has to specifically test for it.
That is unacceptable. It is very good to have the possibility to specify
formatting but
1. It should not be the only way to do things.
2. The method should really not be called toString, but writeTo.
