dmd 1.057 and 2.041 release

Steven Schveighoffer schveiguy at yahoo.com
Mon Mar 8 11:57:55 PST 2010


On Mon, 08 Mar 2010 14:49:33 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> bearophile wrote:
>> Andrei Alexandrescu:
>>
>>> Sorry, this stays.
>>  Then I'm not going to use the Phobos printing in all my future D2
>> programs. As I was not using it in D1. I'm not going to change idea
>> on this.
>>
>>> (e.g. the comma may be a decimal point in some languages, so is
>>> [1,2] in a German locale an array of double with one value or two?<
>>>
>>  In German you need no space after the comma, and there's no [] after
>> and before it. So [1, 2] is not a floating point value in German.
>>
>>> Why one space?<
>>  Because that's they way people print things in natural languages.
>> It's a convention, you know. And it's a good one. It tells apart the
>> FP numbers and it's the minimal.
>>
>>> It's the most neutral thing I could think of. Why no brackets?
>>> Because of minimalism. You can very easy add them if you want
>>> them.<
>>  The purpose of things like the square brackets is to give a less
>> ambiguous textual representation of the most common data structures
>> (array and strings are the most common after numbers). So you put ""
>> or '' around strings and [] to know what you are printing.
>
> Your choice of leading/trailing symbols and of separators makes 'to'  
> friendlier for printing e.g. debug strings. My choice makes it a  
> primitive for text serialization. I'm not 100% sure which is the more  
> frequent use and therefore which is the most appropriate as a default,  
> but I'm leaning towards the latter.

No it doesn't.

Tell me how you would parse the following text serialization string for a  
string[]:

hello world how are you

What if it was a string[][]?

Compare that to:

[hello world, [how are, you]]

That is almost completely unambiguous (you still have to account for  
literal commas or brackets), whereas you have a multitude of choices with  
the first version.

The thing is, friendlier for text-based serialization is almost identical  
to friendlier for printing.  In fact, friendlier for text-based  
serialization should have even more annotations to escape delimiters.

In fact, I find the defaults you defined not useful in most cases.   
Printing or serializing, I want to see the delimiters for the arrays,  
elements, and subarrays.

-Steve


More information about the Digitalmars-d-announce mailing list