phobos / tango / ares

Sean Kelly sean at
Fri Feb 9 08:16:49 PST 2007

Kevin Bealer wrote:
> Okay -- I'm really sorry if any of this seems to have a negative tone. I 
> hesitate to write this since I have a lot of respect for the Tango 
> design in general, but there are a couple of friction points I've noticed.
> 1. writefln / format replacements
> Concerning standard output and string formatting, in phobos I can do 
> these operations:
>   writefln("%s %s %s", a, b, c);
>   format("%s %s %s", a, b, c);
> How do I do these in Tango?  The change to "{0} {1}" stuff is fine with 
> me, in fact I like it, but this syntax:
>   Stdout.formatln("{0} {1} {2}", a, b, c);
>   Format!(char).convert("{0} {1} {2}", a, b, c);
> Is awkward.  And these statements are used *all the time*.  In a recent 
> toy project I wrote, I used Stdout 15 times, compared to using "foreach" 
> only 8 times.  I also use the "format to string" idiom a lot (oddly 
> enough, not in that project), and it's even more awkward.

The conversion modules seem to have slightly spotty API documentation, 
but I think this will work for the common case:

Formatter( "{0} {1} {2}", a, b, c );

The Stdout design is the result of a lengthy discussion involving 
overload rules and expected behavior.  I believe two of the salient 
points were that the default case should be the simplest to execute, and 
that the .format method call provided a useful signifier that an 
explicit format was being supplied.  That said, I believe that the 
default output format can be called via:

Stdout( a, b, c );

or the "whisper" syntax:

Stdout( a )( b )( c );

> That's why I think phobos really did the "Right Thing" by keeping those 
> down to one token.  Second, the fact that the second one does exactly 
> what the first does but you need to build a template, etc, is annoying. 
>  I kept asking myself if I was doing the right thing because it seemed 
> like I was using too much syntax for this kind of operation (I'm still 
> not sure it's the best way to go -- is it?)

Do you consider the Formatter instance to be sufficient or would it be 
more useful to wrap this behavior in a free function?  I'll admit that, 
being from a C++ background I'm quite used to customizing the library 
behavior to suit my particular use style, but I can understand the 
desire for "out of the box" convenience.

> 2. toString and toUtf8 (collisions)
> The change of the terminology is actually okay with me.
> But phobos has a way of using toString as both a method and a top-level 
> function name, all over the place.  This gets really clumsy because you 
> can never use the top level function names when writing a class unless 
> you fully qualify them.
> For example, std.cpuid.toString(), always has to be fully qualified when 
> called from a class, and seems nondescriptive anyway.  All the 
> std.conv.toString() functions are nice but it's easy to accidentally 
> call the in-class toString() by accident.
> For the utf8 <--> utf16 and similar, it's frustrating to have to do this:
> dchar[] x32 = ...;
> char[] x8 = tango.text.convert.Utf.toUtf8(x32);
> But you have to fully qualify if you are writing code in any class or 
> struct.  If these were given another name, like makeUtf8, then these 
> collisions would not happen.

One aspect of the Mango design that has carried forward into Tango is 
that similar functions are typically intended to live in their own 
namespace for the sake of clarity.  Previously, most/all of the free 
functions were declared in structs simply to prevent collisions, but 
this had code bloat issues so the design was changed.  Now, users are 
encouraged to use the aliasing import to produce the same effect:

import Utf = tango.text.convert.Utf;

Utf.toUtf8( x32 );

I'll admit it's not as convenient as simply importing and using the 
functions, but it does make the origin of every function call quite 
clear.  I personally avoid "using" in C++ for exactly this reason--if 
I'm using an external routine I want to know what library it's from by 


More information about the Digitalmars-d-learn mailing list