toString or not toString

Timon Gehr timon.gehr at gmx.ch
Wed Aug 31 05:30:05 PDT 2011


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.






More information about the Digitalmars-d mailing list