dmd 1.057 and 2.041 release

[Andrei Alexandrescu]

Steven Schveighoffer wrote:
> 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.

I think it also means that you write your function that calls "to" 
inside, and use your function throughout.

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

Printing values with spaces between them is entirely fine for e.g. all 
numbers.

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

Write your own function and call it.

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

I guess that should be changed too :o).


Andrei