I don't want to divert anyone's attention from more important issues,
but I'm running into a few little problems here with writef and friends.
1. Printing only some arguments
Currently writef insist on formatting all arguments, even those that
don't have a format spec allocated. This creates problem in an app of
mine that takes a format string as a command-line argument and
selectively prints stuff. For example:
./kernelize --format='%1$s %2$s'
The call is:
uint id1, id2;
float value;
...
writefln(format, id1, id2, value);
I need:
12 23
But instead I get:
12 230.34
I wonder how this could be addressed. Should presence of positional
parameters suppress the "print'em all" approach?
2. Formatting arrays
This has been an ongoing problem with formatting functions: there's no
proper formatting for arrays beyound writing %s and formatting the
entire array with [e0 e1 ... en]. I was thinking of improving that like
this:
int[] a = [ 42, 1, 2 ];
writefln("%(s, )", a); // prints "42, 1, 2"
"%(" opens a spec that will be applied to each element of the array. For
the last element, only the format part of the spec applies, not the
trailing string (in the example above ", "). One nice thing is that the
specs can be nested, so:
int[][] a = [ [ 42, 1, 2 ], [ 3, 4 ] ];
writefln("%((s, )\n)", a); // prints "42, 1, 2"
will print:
42, 1, 2
3, 4
that is, one subarray per line with elements separated with commas and
spaces.
Is this something you'd use?
Andrei

I don't want to divert anyone's attention from more important issues, but
I'm running into a few little problems here with writef and friends.
1. Printing only some arguments
Currently writef insist on formatting all arguments, even those that don't
have a format spec allocated. This creates problem in an app of mine that
takes a format string as a command-line argument and selectively prints
stuff. For example:
./kernelize --format='%1$s %2$s'
The call is:
uint id1, id2;
float value;
...
writefln(format, id1, id2, value);
I need:
12 23
But instead I get:
12 230.34
I wonder how this could be addressed. Should presence of positional
parameters suppress the "print'em all" approach?

It is this way in Tango AFAIK. You could write a wrapper for it (in
pseudocode):
writefln2(string format, ...)
{
x = count % in format;
return writefln(format, varargs[0..x]);
}

2. Formatting arrays
This has been an ongoing problem with formatting functions: there's no
proper formatting for arrays beyound writing %s and formatting the entire
array with [e0 e1 ... en]. I was thinking of improving that like this:
int[] a = [ 42, 1, 2 ];
writefln("%(s, )", a); // prints "42, 1, 2"
"%(" opens a spec that will be applied to each element of the array. For
the last element, only the format part of the spec applies, not the
trailing string (in the example above ", "). One nice thing is that the
specs can be nested, so:
int[][] a = [ [ 42, 1, 2 ], [ 3, 4 ] ];
writefln("%((s, )\n)", a); // prints "42, 1, 2"
will print:
42, 1, 2
3, 4
that is, one subarray per line with elements separated with commas and
spaces.
Is this something you'd use?

That is a very good idea! Tango is the same way, in fact, tango got ability
to print arrays fairly recently. If I used Phobos, I'd certainly use it.
How many times I wanted to print an array of ints as hexadecimal, but was
forced to do some stupid loop thing...
I'll propose something similar on Tango as well.
-Steve

I don't want to divert anyone's attention from more important issues,
but I'm running into a few little problems here with writef and friends.
1. Printing only some arguments
Currently writef insist on formatting all arguments, even those that
don't have a format spec allocated. This creates problem in an app of
mine that takes a format string as a command-line argument and
selectively prints stuff. For example:
./kernelize --format='%1$s %2$s'
The call is:
uint id1, id2;
float value;
...
writefln(format, id1, id2, value);
I need:
12 23
But instead I get:
12 230.34
I wonder how this could be addressed. Should presence of positional
parameters suppress the "print'em all" approach?

Positional formatting would be great. Maybe make it zero-based? Would
it conflict with the '0' flag then? Or $ is enough to disambiguate?
What about making %1 a shortcut for %1$s?

2. Formatting arrays
This has been an ongoing problem with formatting functions: there's no
proper formatting for arrays beyound writing %s and formatting the
entire array with [e0 e1 ... en]. I was thinking of improving that like
this:
int[] a = [ 42, 1, 2 ];
writefln("%(s, )", a); // prints "42, 1, 2"
"%(" opens a spec that will be applied to each element of the array. For
the last element, only the format part of the spec applies, not the
trailing string (in the example above ", "). One nice thing is that the
specs can be nested, so:
int[][] a = [ [ 42, 1, 2 ], [ 3, 4 ] ];
writefln("%((s, )\n)", a); // prints "42, 1, 2"
will print:
42, 1, 2
3, 4
that is, one subarray per line with elements separated with commas and
spaces.
Is this something you'd use?

2. Formatting arrays
This has been an ongoing problem with formatting functions: there's no
proper formatting for arrays beyound writing %s and formatting the
entire array with [e0 e1 ... en]. I was thinking of improving that like
this:
int[] a = [ 42, 1, 2 ];
writefln("%(s, )", a); // prints "42, 1, 2"
"%(" opens a spec that will be applied to each element of the array. For
the last element, only the format part of the spec applies, not the
trailing string (in the example above ", "). One nice thing is that the
specs can be nested, so:
int[][] a = [ [ 42, 1, 2 ], [ 3, 4 ] ];
writefln("%((s, )\n)", a); // prints "42, 1, 2"
will print:
42, 1, 2
3, 4

The need to format single items of an array isn't so much common, but it's
common enough to be an interesting case. I may be better to reduce the
complexity of your idea: you can specify just the type of the bottom level of
the given _collection_, and you can't specify the separator. It's less
flexible, but I think it covers most of the common situations. So the syntax
becomes the following in both cases:
%(s)
A syntax like %(s:s) may be used to specify how to format the bottom levels of
associative arrays :-)
Bye,
bearophile

I don't want to divert anyone's attention from more important issues,
but I'm running into a few little problems here with writef and friends.
1. Printing only some arguments
Currently writef insist on formatting all arguments, even those that
don't have a format spec allocated. This creates problem in an app of
mine that takes a format string as a command-line argument and
selectively prints stuff. For example:
./kernelize --format='%1$s %2$s'
The call is:
uint id1, id2;
float value;
...
writefln(format, id1, id2, value);
I need:
12 23
But instead I get:
12 230.34
I wonder how this could be addressed. Should presence of positional
parameters suppress the "print'em all" approach?

Just use/add the C# (Tango) formatting scheme?

2. Formatting arrays
This has been an ongoing problem with formatting functions: there's no
proper formatting for arrays beyound writing %s and formatting the
entire array with [e0 e1 ... en]. I was thinking of improving that like
this:
int[] a = [ 42, 1, 2 ];
writefln("%(s, )", a); // prints "42, 1, 2"
"%(" opens a spec that will be applied to each element of the array. For
the last element, only the format part of the spec applies, not the
trailing string (in the example above ", "). One nice thing is that the
specs can be nested, so:
int[][] a = [ [ 42, 1, 2 ], [ 3, 4 ] ];
writefln("%((s, )\n)", a); // prints "42, 1, 2"
will print:
42, 1, 2
3, 4
that is, one subarray per line with elements separated with commas and
spaces.
Is this something you'd use?
Andrei

I wonder how this could be addressed. Should presence of positional
parameters suppress the "print'em all" approach?

Just use/add the C# (Tango) formatting scheme?

How does that work?

eh.. I'm not sure people who like Phobos/writef would like it ;)
Technically this is not an enabler for allowing preventing the 'print 'em
all' approach:
Stdout.formatln("{1}, {0}", "arg1", "arg2", "arg3");
prints "arg2, arg1"
It's just the approach that arguments must be specified in the format string
to be printed. The format of the token identifiers really isn't important
here, you can use the same philosophy with %s tokens, as you said.
-Steve