RE: [boost] Boost.Format syntax

From: Brey, Edward D (EdwardDBrey_at_[hidden])
Date: 2002-01-28 11:07:02

> From: Darin Adler [mailto:darin_at_[hidden]]
> 
> > I've been putting some thought into the syntax of 
> Boost.Format, and have
> > come to see that the best syntax going forward is one that 
> does not try to
> > retain compatibility with printf as a high priority.
> 
> I don't agree with this premise.

Even though that statement was at the top of my email, it isn't really a
premise.  It's really a conclusion.  Printf compatibility and elegant syntax
are mutually exclusive, in light of what can be done with more modern
syntaxes.  Therefore, ... (the above).
 
> While I think it might be useful to pursue a 
> string-formatting library that
> doesn't have printf compatibility, I do think that a library 
> that provides
> printf compatibility is quite useful, and is nearly 
> accomplished with the
> proposed format library. That is the reason I propose 
> removing the "%1" from
> the library and retaining only the "%1$s" form. I don't think that the
> precedence problem with operator % is severe.

I agree with the desire for printf compatibility.  But trying to find a nice
syntax that allows it just isn't easy.  For example, using the "%1$s" use
mentioned above, what happens if the value substituted is a string that the
context string will make plural.  Its not pretty: format("%1$s %2$ss") [3]
["banana"].

What harm is there in completely separating the printf syntax into a
different class?  Is there really any desire to use (pseudo-)printf syntax
and a modern syntax within the same format object?

> For what it's worth, where printf compatibility is not an issue in my
> programs, I use a formatting system with a syntax like this:
> 
>     "There's no space left on the disk named <disk>."

You're in luck.  C++ has this!
cout << "There's no space left on the disk named " << disk << ".";

<big grin>
Of course, I agree with you.  Something like this could be quite nice to
have.

> I find that the named parameters are easier to understand for 
> translators
> than numbered ones would be. And I don't try to create a 
> terse C++ syntax
> for this. I find that a normal sequence of function calls is 
> just fine.

This obviously goes down the path of personal preference.  However, I think
that existing languages can shed some light.  Note how modern languages that
provide named function parameters (e.g. Python), still allow positional
parameters.  There must be some value to them.  Likewise, note the tuple
library in Boost.  Wouldn't structs be good enough?  The parallel isn't
100%, but it does indicate that there is some value to positional references
when dealing with a small number of arguments.