dmd 1.057 and 2.041 release
Andrei Alexandrescu
SeeWebsiteForEmail at erdani.org
Mon Mar 8 12:56:14 PST 2010
Steven Schveighoffer wrote:
> 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.
I said a primitive for serialization, not a serialization
infrastructure. So the basic idea is that you use "to" in conjunctions
with your own routines to serialize things. "to" imposes no policy.
Using "[", ", ", and "]" is policy.
> 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.
You can choose them no problem. std.conv gives you mechanism, you choose
the policy.
Andrei
More information about the Digitalmars-d-announce
mailing list