toString or not toString

Don nospam at nospam.com
Wed Aug 31 01:51:14 PDT 2011


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.



More information about the Digitalmars-d mailing list