dmd 1.057 and 2.041 release

[Steven Schveighoffer]

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

> 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.

Reading the documentation, it appears that setting the policy means simply  
passing delimiters to the "to" function.  That means that for every call  
to "to", you specify the policy if it differs from the default.  Since the  
default is not useful for serialization and confusing for printing, why  
would anyone use the default policy (aside from the obvious "because it's  
annoying")?  If you don't use the default policy, why have a default, why  
not require the policy for each call?

>> 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.

I can choose the policy for each call, that is not going to look very  
good, and be very tedious to write.  Plus it's not recursive (this would  
actually be a huge problem if using to for serialization):


import std.stdio;
import std.conv;
void main()
{
     int[][] x = new int[][](2, 2);
     writeln(to!string(x, "[", ",", "]"));
}

outputs [0 0,0 0]

I would expect [[0,0],[0,0]]

I'll also point out that AAs have a default policy that is much more  
reasonable.

-Steve