On Wednesday, August 31, 2011 10:51:14 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.
Actually, I pretty much never do. I can understand wanting to, and I agree
that it would be useful to do so with BigFloat, but I disagree that that's
what you _always_ want. If anything, I typically avoid using anything other
than %s in format strings. Sometimes, you need to be more specific, but for
what I do, at least, it's rarely useful.
> > 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.
Java has a toString which doesn't take any arguments, and it works fine. I've
never had a problem with it, and the only real issue that I've had with
toString in D is the fact that you can't use any attributes such as const or
pure on struct's toString thanks to bug# 3659. In fact, before you brought up
this issue, it never even occured to me that there was one. So, while I agree
with you that we should find a good solution for this issue (and writeTo may
very well be it), I disagree that this is generally a big deal. It really does
feel to me like you're blowing this issue out of proportion. Maybe you just
deal with numeric stuff way more than I do, but I've _never_ felt the lack of a
format string with toString.
Regardless, while I don't think that this is a big issue, I have no problem
with us reworking toString/writeTo so that the issue is fixed.
- Jonathan M Davis
