phobos commit, revision 1748


user: andrei

msg:
Radical overhaul.

http://www.dsource.org/projects/phobos/changeset/1748

This is great, and it was sorely needed!

Have you given any more thought to the issue of user-defined types that want to define a more elaborate toString() signature than the trivial one?

It seems that with your recent change to output ranges, both
BigInt-style toString(),

    void toString(void delegate(const(char)[]) sink, string fmt);

and Complex-style toString(),

    void toString(Writer)(ref Writer writer, string fmt)
        if (isOutputRange!(Writer,string))

could be supported without making special cases for each.

-Lars



On Sun, 2010-07-11 at 20:49 -0400, dsource.org wrote:
> phobos commit, revision 1748
> 
> 
> user: andrei
> 
> msg:
> Radical overhaul.
> 
> http://www.dsource.org/projects/phobos/changeset/1748
> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

Yah, I was thinking of a unified and backwards-compatible sig:

string toString(void delegate(const(char)[]) sink = null,
     string fmt = null);

With null inputs toString works like today. When provided a sink, it outputs to the sink and returns null.


Andrei

On 07/12/2010 01:28 AM, Lars Tandle Kyllingstad wrote:
> This is great, and it was sorely needed!
>
> Have you given any more thought to the issue of user-defined types that want to define a more elaborate toString() signature than the trivial one?
>
> It seems that with your recent change to output ranges, both
> BigInt-style toString(),
>
>      void toString(void delegate(const(char)[]) sink, string fmt);
>
> and Complex-style toString(),
>
>      void toString(Writer)(ref Writer writer, string fmt)
>          if (isOutputRange!(Writer,string))
>
> could be supported without making special cases for each.
>
> -Lars
>
>
>
> On Sun, 2010-07-11 at 20:49 -0400, dsource.org wrote:
>> phobos commit, revision 1748
>>
>>
>> user: andrei
>>
>> msg:
>> Radical overhaul.
>>
>> http://www.dsource.org/projects/phobos/changeset/1748
>>
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
>
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

(Sorry, sent this to Andrei's private address.  Resending to list.)

That sounds like a good idea.  Should fmt include the '%' character of the format specifier?

-Lars



On Mon, 2010-07-12 at 01:38 -0500, Andrei Alexandrescu wrote:
> Yah, I was thinking of a unified and backwards-compatible sig:
> 
> string toString(void delegate(const(char)[]) sink = null,
>      string fmt = null);
> 
> With null inputs toString works like today. When provided a sink, it outputs to the sink and returns null.
> 
> 
> Andrei
> 
> On 07/12/2010 01:28 AM, Lars Tandle Kyllingstad wrote:
> > This is great, and it was sorely needed!
> >
> > Have you given any more thought to the issue of user-defined types that want to define a more elaborate toString() signature than the trivial one?
> >
> > It seems that with your recent change to output ranges, both
> > BigInt-style toString(),
> >
> >      void toString(void delegate(const(char)[]) sink, string fmt);
> >
> > and Complex-style toString(),
> >
> >      void toString(Writer)(ref Writer writer, string fmt)
> >          if (isOutputRange!(Writer,string))
> >
> > could be supported without making special cases for each.
> >
> > -Lars
> >
> >
> >
> > On Sun, 2010-07-11 at 20:49 -0400, dsource.org wrote:
> >> phobos commit, revision 1748
> >>
> >>
> >> user: andrei
> >>
> >> msg:
> >> Radical overhaul.
> >>
> >> http://www.dsource.org/projects/phobos/changeset/1748
> >>
> >> _______________________________________________
> >> phobos mailing list
> >> phobos at puremagic.com
> >> http://lists.puremagic.com/mailman/listinfo/phobos
> >
> >
> > _______________________________________________
> > phobos mailing list
> > phobos at puremagic.com
> > http://lists.puremagic.com/mailman/listinfo/phobos

On 07/12/2010 03:04 AM, Lars Tandle Kyllingstad wrote:
> (Sorry, sent this to Andrei's private address.  Resending to list.)
>
> That sounds like a good idea.  Should fmt include the '%' character of the format specifier?

I'd think so. Also, types could define their own format specifiers if they want to.

BTW I've changed the grammar of the format specifiers to allow unlimited nesting. A format string may contain a nested format string by enclosing it in %( and %). The intent is to print elaborate types comfortably. For example, this:

int[string] a = ["abc":1, "def":5];
writefln("Here's the map:\n"
     "%(=== %2$ is mapped by %1$ ===\n%) ===\n\nThat was it", a);

produces:

Here's the map:
=== 1 is mapped by abc ===
=== 2 is mapped by def ===

(I've also showcased positional parameters.) Note how the nested specifier is used for each <key,value> pair in the map. The last time around the trailing specifier is not printed in order to allow e.g. printing arrays without a trailing comma. This time I did want the trailing portion to be present for the last element, so I added it after the nested specifier.

The format string above is parsed correctly but the current version doesn't support associative arrays yet.

Now getting back to types defining their own format specifiers, for example Data could define its own spec that understands %D, %M, and %Y. Then you could print stuff like this:

Date d;
double x;
writefln("I paid $%g on %(%M/%D/%Y%)", x, d);

producing:

I paid $5 on 07/12/2010

The nested specifier is passed to Date's toString function along with a delegate that writes to the standard output.


Andrei