digitalmars.D - stream.scanf change proposal
- "Ben Hinkle" <ben.hinkle gmail.com> Jun 30 2005
- "Regan Heath" <regan netwin.co.nz> Jun 30 2005
- "Andrew Fedoniouk" <news terrainformatica.com> Jun 30 2005
- Sean Kelly <sean f4.ca> Jun 30 2005
- "Andrew Fedoniouk" <news terrainformatica.com> Jun 30 2005
- Sean Kelly <sean f4.ca> Jun 30 2005
- "Andrew Fedoniouk" <news terrainformatica.com> Jun 30 2005
- Sean Kelly <sean f4.ca> Jul 01 2005
- =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> Jul 01 2005
- "Andrew Fedoniouk" <news terrainformatica.com> Jul 01 2005
- Sean Kelly <sean f4.ca> Jul 01 2005
- "Ben Hinkle" <ben.hinkle gmail.com> Jul 02 2005
- Sean Kelly <sean f4.ca> Jul 02 2005
- "Ben Hinkle" <ben.hinkle gmail.com> Jul 02 2005
- Sean Kelly <sean f4.ca> Jul 02 2005
- "Ben Hinkle" <ben.hinkle gmail.com> Jul 01 2005
- Sean Kelly <sean f4.ca> Jun 30 2005
- Nick <Nick_member pathlink.com> Jul 01 2005
- "Ben Hinkle" <bhinkle mathworks.com> Jul 01 2005
- Nick <Nick_member pathlink.com> Jul 01 2005
Vathix's post on the bugs newsgroup about std.stream issue raised the topic
of reading and converting text input to binary data like ints and floats and
such. Currently std.stream has a scanf and vscanf that were written ages ago
(probably before _argptr and _arguments existed) and I'd like to update them
to the more modern D style much like Sean's unformat and/or readf. So
basically the change would be to change the signature of scanf and vscanf
from
int scanf(char[] fmt, ...);
int vscanf(char[] fmt, va_list args);
to
int scanf(...);
int vscanf(TypeInfo[] arguments, va_list args);
and modify the format specifiers to match std.format instead of std.c.stdio.
In other words if the format string is omitted then the TypeInfo for the
argument is used to deduce a default format. For instance
int x,y,z;
din.scanf(&x, &y," and then ", &z);
would take an input line like "123 567 and then 987" and fill x with 123, y
with 567 and z with 987. Explicit format specifiers would be allowed, too.
eg din.scanf("%d %d and then %d",&x,&y,&z);
Such a change is not backwards compatible with previous dmd versions but I
think it is worth breaking from the C style in this case. The last example
indicates many simple scanf calls will continue to work just fine. From what
I can tell this is very similar to what Sean has implemented.
thoughts?
Jun 30 2005
"Regan Heath" <regan netwin.co.nz> I like it. But, I've never used scanf in C, and I haven't yet used it in D either. So I might not have the right perspective to answer. Regan On Thu, 30 Jun 2005 21:53:01 -0400, Ben Hinkle <ben.hinkle gmail.com> wrote:Vathix's post on the bugs newsgroup about std.stream issue raised the topic of reading and converting text input to binary data like ints and floats and such. Currently std.stream has a scanf and vscanf that were written ages ago (probably before _argptr and _arguments existed) and I'd like to update them to the more modern D style much like Sean's unformat and/or readf. So basically the change would be to change the signature of scanf and vscanf from int scanf(char[] fmt, ...); int vscanf(char[] fmt, va_list args); to int scanf(...); int vscanf(TypeInfo[] arguments, va_list args); and modify the format specifiers to match std.format instead of std.c.stdio. In other words if the format string is omitted then the TypeInfo for the argument is used to deduce a default format. For instance int x,y,z; din.scanf(&x, &y," and then ", &z); would take an input line like "123 567 and then 987" and fill x with 123, y with 567 and z with 987. Explicit format specifiers would be allowed, too. eg din.scanf("%d %d and then %d",&x,&y,&z); Such a change is not backwards compatible with previous dmd versions but I think it is worth breaking from the C style in this case. The last example indicates many simple scanf calls will continue to work just fine. From what I can tell this is very similar to what Sean has implemented. thoughts?
Jun 30 2005
Ben, small question:
Lets say we have:
char* a;
char* b;
How then you will distinguish cases:
din.scanf("%s",a);
din.scanf(a, b);
If we would have const and const literals then it will be possible.
But without them it is sort of ambiguity as far as I understand.
Correct me if....
Andrew.
In other words if the format string is omitted then the TypeInfo for the
argument is used to deduce a default format. For instance
"Ben Hinkle" <ben.hinkle gmail.com> wrote in message
news:da27lu$2i9v$1 digitaldaemon.com...
Vathix's post on the bugs newsgroup about std.stream issue raised the
topic of reading and converting text input to binary data like ints and
floats and such. Currently std.stream has a scanf and vscanf that were
written ages ago (probably before _argptr and _arguments existed) and I'd
like to update them to the more modern D style much like Sean's unformat
and/or readf. So basically the change would be to change the signature of
scanf and vscanf from
int scanf(char[] fmt, ...);
int vscanf(char[] fmt, va_list args);
to
int scanf(...);
int vscanf(TypeInfo[] arguments, va_list args);
and modify the format specifiers to match std.format instead of
std.c.stdio. In other words if the format string is omitted then the
TypeInfo for the argument is used to deduce a default format. For instance
int x,y,z;
din.scanf(&x, &y," and then ", &z);
would take an input line like "123 567 and then 987" and fill x with 123,
y with 567 and z with 987. Explicit format specifiers would be allowed,
too. eg din.scanf("%d %d and then %d",&x,&y,&z);
Such a change is not backwards compatible with previous dmd versions but I
think it is worth breaking from the C style in this case. The last example
indicates many simple scanf calls will continue to work just fine. From
what I can tell this is very similar to what Sean has implemented.
thoughts?
Jun 30 2005
In article <da2bs0$2ptk$1 digitaldaemon.com>, Andrew Fedoniouk says...Ben, small question: Lets say we have: char* a; char* b; How then you will distinguish cases: din.scanf("%s",a); din.scanf(a, b); If we would have const and const literals then it will be possible. But without them it is sort of ambiguity as far as I understand.
The way I did this was kind of weird. I assumed that D arrays (char[], etc) were format strings and C pointers and pointers to arrays (ie. char*, char[]*, etc) were input parameters. Sean
Jun 30 2005
"Sean Kelly" <sean f4.ca> wrote in message news:da2ejm$2s5v$1 digitaldaemon.com...In article <da2bs0$2ptk$1 digitaldaemon.com>, Andrew Fedoniouk says...Ben, small question: Lets say we have: char* a; char* b; How then you will distinguish cases: din.scanf("%s",a); din.scanf(a, b); If we would have const and const literals then it will be possible. But without them it is sort of ambiguity as far as I understand.
The way I did this was kind of weird. I assumed that D arrays (char[], etc) were format strings and C pointers and pointers to arrays (ie. char*, char[]*, etc) were input parameters.
I see. A bit optimstic, IMO. Why just not use another and distinct function for that? Like parse()? In any case classic scanf (with explicit format) combined with D's TypeInfo[] vector is unbeatable, IMO. Andrew.Sean
Jun 30 2005
In article <da2n8i$2gc$1 digitaldaemon.com>, Andrew Fedoniouk says...The way I did this was kind of weird. I assumed that D arrays (char[], etc) were format strings and C pointers and pointers to arrays (ie. char*, char[]*, etc) were input parameters.
I see. A bit optimstic, IMO.
Since D doesn't allow 'inout' varargs, I thought it quite unlikely someone would pass a standard array in to be written into. And I thought it was reasonable to assert that all pointer types were input parameters (particularly since literal strings are typed as arrays, not char pointers).Why just not use another and distinct function for that? Like parse()?
The first cut implemented the C99 scanf spec exactly, so this wasn't an option.In any case classic scanf (with explicit format) combined with D's TypeInfo[] vector is unbeatable, IMO.
I personally like the way I have it now--format strings are only necessary if you're expecting something in an odd format or if you want to match (and ignore) portions of the input stream. But it would be easy enough to always interpret the first argument as a format string. Sean
Jun 30 2005
"Sean Kelly" <sean f4.ca> wrote in message news:da2o30$39n$1 digitaldaemon.com...In article <da2n8i$2gc$1 digitaldaemon.com>, Andrew Fedoniouk says...The way I did this was kind of weird. I assumed that D arrays (char[], etc) were format strings and C pointers and pointers to arrays (ie. char*, char[]*, etc) were input parameters.
I see. A bit optimstic, IMO.
Since D doesn't allow 'inout' varargs, I thought it quite unlikely someone would pass a standard array in to be written into. And I thought it was reasonable to assert that all pointer types were input parameters (particularly since literal strings are typed as arrays, not char pointers).Why just not use another and distinct function for that? Like parse()?
The first cut implemented the C99 scanf spec exactly, so this wasn't an option.
Seems like I didn't get something.... My thought was: scanf(char[], ...); and parse(...); First one used with mandatory format parameter. Second - "formatless" parsing. ------------------- In fact these functions will definitely benefit from const int a; char b[20]; int c[3]; parse(&a, b, " - ", c); will read 20 chars into b; and 3 ints into c; Of course this will work only if string literal will be const char[].In any case classic scanf (with explicit format) combined with D's TypeInfo[] vector is unbeatable, IMO.
I personally like the way I have it now--format strings are only necessary if you're expecting something in an odd format or if you want to match (and ignore) portions of the input stream. But it would be easy enough to always interpret the first argument as a format string. Sean
Andrew.
Jun 30 2005
In article <da2pcb$4k3$1 digitaldaemon.com>, Andrew Fedoniouk says...Seems like I didn't get something.... My thought was: scanf(char[], ...); and parse(...); First one used with mandatory format parameter. Second - "formatless" parsing.
The way readf works now is that it uses certain defaults if no format strings are specified, but format strings can be used to be more specific: int i, j; char[] c; sreadf( "abc 0x1", &c, &i, "x", &j ); // 1 sreadf( "abc 0x1", &c, "%x", &i ); // 2 In 1 above, c will contain 'abc', i will contain '0', and j will contain '1'. In 2, c will contain 'abc', and i will contain '1'. Format strings can be mixed with input arguments. I wouldn't mind renaming readf to parse, but I wouldn't want to lose this degree of flexibility. Another entirely different option for streaming would be to use opCall like Mango does. I like the way this looks, and it sidesteps the problem with using the address-of operator everywhere. The only catch with this method is that there's no good way to handle a bidirectional stream. Sean
Jul 01 2005
Sean Kelly wrote:The way readf works now is that it uses certain defaults if no format strings are specified, but format strings can be used to be more specific: int i, j; char[] c; sreadf( "abc 0x1", &c, &i, "x", &j ); // 1 sreadf( "abc 0x1", &c, "%x", &i ); // 2 In 1 above, c will contain 'abc', i will contain '0', and j will contain '1'. In 2, c will contain 'abc', and i will contain '1'. Format strings can be mixed with input arguments. I wouldn't mind renaming readf to parse, but I wouldn't want to lose this degree of flexibility.
It's also a very good match to "writef", which makes it look sensible. So in my opinion it should keep the name readf, instead of being "parse" BTW; I thought that "unformat" was a much better name than sreadf, but that's a little beside the point... (i.e. std.string.unformat and std.unformat) The naming was carefully chosen to make the "I" match the (current) "O" Details: digitalmars.D/21692 The only "extra" besides C's scanf is to pass pointers to strings too ? (otherwise it wasn't able to separate between formats and string params) Whether it works on FILE* or streams doesn't really "matter" either. And it still needs TypeInfo for pointer types, in order to work OK... --anders
Jul 01 2005
"Sean Kelly" <sean f4.ca> wrote in message news:da2r8l$7g1$1 digitaldaemon.com...In article <da2pcb$4k3$1 digitaldaemon.com>, Andrew Fedoniouk says...Seems like I didn't get something.... My thought was: scanf(char[], ...); and parse(...); First one used with mandatory format parameter. Second - "formatless" parsing.
The way readf works now is that it uses certain defaults if no format strings are specified, but format strings can be used to be more specific: int i, j; char[] c; sreadf( "abc 0x1", &c, &i, "x", &j ); // 1 sreadf( "abc 0x1", &c, "%x", &i ); // 2
Got it, thanks. BTW: "%x" will set hex mode for all consequent ints or just for the next arg? Seems like C++ streams with use of ',' instead of >> ...In 1 above, c will contain 'abc', i will contain '0', and j will contain '1'. In 2, c will contain 'abc', and i will contain '1'. Format strings can be mixed with input arguments. I wouldn't mind renaming readf to parse, but I wouldn't want to lose this degree of flexibility. Another entirely different option for streaming would be to use opCall like Mango does. I like the way this looks, and it sidesteps the problem with using the address-of operator everywhere. The only catch with this method is that there's no good way to handle a bidirectional stream. Sean
Jul 01 2005
In article <da2sfm$8ob$1 digitaldaemon.com>, Andrew Fedoniouk says..."Sean Kelly" <sean f4.ca> wrote in message news:da2r8l$7g1$1 digitaldaemon.com...int i, j; char[] c; sreadf( "abc 0x1", &c, &i, "x", &j ); // 1 sreadf( "abc 0x1", &c, "%x", &i ); // 2
Got it, thanks. BTW: "%x" will set hex mode for all consequent ints or just for the next arg?
Just the next arg.Seems like C++ streams with use of ',' instead of >> ...
It's kind of a hybrid. Internally, the code is basically a pure scanf implementation (as that's what it started as) but now if it doesn't have a format string it checks if the next parameter is one. If so, it uses it until it's exhausted and if not it supplies a default one for that parameter. To be identical to writef, the code would have to allow bit values to be parsed as "true/false" if a "%s" format string is supplied. Sean
Jul 01 2005
"Sean Kelly" <sean f4.ca> wrote in message news:da2o30$39n$1 digitaldaemon.com...In article <da2n8i$2gc$1 digitaldaemon.com>, Andrew Fedoniouk says...The way I did this was kind of weird. I assumed that D arrays (char[], etc) were format strings and C pointers and pointers to arrays (ie. char*, char[]*, etc) were input parameters.
I see. A bit optimstic, IMO.
Since D doesn't allow 'inout' varargs, I thought it quite unlikely someone would pass a standard array in to be written into. And I thought it was reasonable to assert that all pointer types were input parameters (particularly since literal strings are typed as arrays, not char pointers).
I would think passing a buffer to be filled would be fairly common so in my implementation I made %s, when parsing a char[]*, use any buffer that is passed in (appending if the buffer was too short) and assigns a slice of the result when done. For example char[] str = new char[128]; din.readf(&str); with the input "foobar" will fill str with foobar and set its length to 6. If str were left uninitialized or if the input were longer than 128 chars then a new string would be allocated (by appending). If you want to do this sort of thing in a loop you'd probably want something like char[128] buf; while (whatever) { char[] str = buf; // reuse the full buffer each time din.readf(&str); // str now is a slice of buf (or a new array if str is too big) }
Jul 02 2005
In article <da68uh$oph$1 digitaldaemon.com>, Ben Hinkle says..."Sean Kelly" <sean f4.ca> wrote in message news:da2o30$39n$1 digitaldaemon.com...In article <da2n8i$2gc$1 digitaldaemon.com>, Andrew Fedoniouk says...The way I did this was kind of weird. I assumed that D arrays (char[], etc) were format strings and C pointers and pointers to arrays (ie. char*, char[]*, etc) were input parameters.
I see. A bit optimstic, IMO.
Since D doesn't allow 'inout' varargs, I thought it quite unlikely someone would pass a standard array in to be written into. And I thought it was reasonable to assert that all pointer types were input parameters (particularly since literal strings are typed as arrays, not char pointers).
I would think passing a buffer to be filled would be fairly common so in my implementation I made %s, when parsing a char[]*, use any buffer that is passed in (appending if the buffer was too short) and assigns a slice of the result when done. For example char[] str = new char[128]; din.readf(&str); with the input "foobar" will fill str with foobar and set its length to 6. If str were left uninitialized or if the input were longer than 128 chars then a new string would be allocated (by appending). If you want to do this sort of thing in a loop you'd probably want something like char[128] buf; while (whatever) { char[] str = buf; // reuse the full buffer each time din.readf(&str); // str now is a slice of buf (or a new array if str is too big) }
But in both these cases you're passing in a pointer (ie. char[]*). I meant someting like this: char[] buf1, buf2; buf1.length = 100; readf( buf1, &buf2 ); Even though buf1 conceivably has enough space to store an input string, I am treating it as a format string, because if buf1 needs to be expanded then the new string will not be visible once readf returns. buf2, by comparison, was passed by reference, so it can be resized as needed and the changes will be preserved. Sean
Jul 02 2005
"Sean Kelly" <sean f4.ca> wrote in message news:da6k7r$11sk$1 digitaldaemon.com...In article <da68uh$oph$1 digitaldaemon.com>, Ben Hinkle says..."Sean Kelly" <sean f4.ca> wrote in message news:da2o30$39n$1 digitaldaemon.com...In article <da2n8i$2gc$1 digitaldaemon.com>, Andrew Fedoniouk says...The way I did this was kind of weird. I assumed that D arrays (char[], etc) were format strings and C pointers and pointers to arrays (ie. char*, char[]*, etc) were input parameters.
I see. A bit optimstic, IMO.
Since D doesn't allow 'inout' varargs, I thought it quite unlikely someone would pass a standard array in to be written into. And I thought it was reasonable to assert that all pointer types were input parameters (particularly since literal strings are typed as arrays, not char pointers).
I would think passing a buffer to be filled would be fairly common so in my implementation I made %s, when parsing a char[]*, use any buffer that is passed in (appending if the buffer was too short) and assigns a slice of the result when done. For example char[] str = new char[128]; din.readf(&str); with the input "foobar" will fill str with foobar and set its length to 6. If str were left uninitialized or if the input were longer than 128 chars then a new string would be allocated (by appending). If you want to do this sort of thing in a loop you'd probably want something like char[128] buf; while (whatever) { char[] str = buf; // reuse the full buffer each time din.readf(&str); // str now is a slice of buf (or a new array if str is too big) }
But in both these cases you're passing in a pointer (ie. char[]*). I meant someting like this: char[] buf1, buf2; buf1.length = 100; readf( buf1, &buf2 ); Even though buf1 conceivably has enough space to store an input string, I am treating it as a format string, because if buf1 needs to be expanded then the new string will not be visible once readf returns. buf2, by comparison, was passed by reference, so it can be resized as needed and the changes will be preserved.
Agreed. My code does the same. The difference I was trying to highlight was the case when buf2 has non-zero length before the call the readf. I got the impression your implementation would not use the passed in buf2 - is that correct? I might have misunderstood that the buffer will be filled.
Jul 02 2005
In article <da6l90$12s5$1 digitaldaemon.com>, Ben Hinkle says..."Sean Kelly" <sean f4.ca> wrote in message news:da6k7r$11sk$1 digitaldaemon.com...But in both these cases you're passing in a pointer (ie. char[]*). I meant someting like this: char[] buf1, buf2; buf1.length = 100; readf( buf1, &buf2 ); Even though buf1 conceivably has enough space to store an input string, I am treating it as a format string, because if buf1 needs to be expanded then the new string will not be visible once readf returns. buf2, by comparison, was passed by reference, so it can be resized as needed and the changes will be preserved.
Agreed. My code does the same. The difference I was trying to highlight was the case when buf2 has non-zero length before the call the readf. I got the impression your implementation would not use the passed in buf2 - is that correct? I might have misunderstood that the buffer will be filled.
That's essentially correct. My implementation deals only with dchars and does a UTF conversion if necessary when writing the output string. So any way you cut it, a temporary dchar buffer is being filled with input chars. I suppose I could have tried to use the existing buffer instead and perhaps done the UTF conversion a char at a time as data was processed. Perhaps I'll look into it if I find some time. Sean
Jul 02 2005
"Andrew Fedoniouk" <news terrainformatica.com> wrote in message news:da2bs0$2ptk$1 digitaldaemon.com...Ben, small question: Lets say we have: char* a; char* b; How then you will distinguish cases: din.scanf("%s",a); din.scanf(a, b);
I'm not sure what you're getting at exactly but what I currently have din.scanf("%s",a) will read one word and store it in a like scanf used to. The second case din.scanf(a,b); will read two characters and store the first in *a and the second in *b. Do you mean char[] a and char[] b? The way I have scanf distinguishing format strings from everything is that a format string is a char[] and everything else must be a pointer to something. It seems natural, simple and unambiguous.If we would have const and const literals then it will be possible. But without them it is sort of ambiguity as far as I understand. Correct me if.... Andrew.In other words if the format string is omitted then the TypeInfo for the argument is used to deduce a default format. For instance
"Ben Hinkle" <ben.hinkle gmail.com> wrote in message news:da27lu$2i9v$1 digitaldaemon.com...Vathix's post on the bugs newsgroup about std.stream issue raised the topic of reading and converting text input to binary data like ints and floats and such. Currently std.stream has a scanf and vscanf that were written ages ago (probably before _argptr and _arguments existed) and I'd like to update them to the more modern D style much like Sean's unformat and/or readf. So basically the change would be to change the signature of scanf and vscanf from int scanf(char[] fmt, ...); int vscanf(char[] fmt, va_list args); to int scanf(...); int vscanf(TypeInfo[] arguments, va_list args); and modify the format specifiers to match std.format instead of std.c.stdio. In other words if the format string is omitted then the TypeInfo for the argument is used to deduce a default format. For instance int x,y,z; din.scanf(&x, &y," and then ", &z); would take an input line like "123 567 and then 987" and fill x with 123, y with 567 and z with 987. Explicit format specifiers would be allowed, too. eg din.scanf("%d %d and then %d",&x,&y,&z); Such a change is not backwards compatible with previous dmd versions but I think it is worth breaking from the C style in this case. The last example indicates many simple scanf calls will continue to work just fine. From what I can tell this is very similar to what Sean has implemented. thoughts?
Jul 01 2005
In article <da27lu$2i9v$1 digitaldaemon.com>, Ben Hinkle says...Vathix's post on the bugs newsgroup about std.stream issue raised the topic of reading and converting text input to binary data like ints and floats and such. Currently std.stream has a scanf and vscanf that were written ages ago (probably before _argptr and _arguments existed) and I'd like to update them to the more modern D style much like Sean's unformat and/or readf.
I think it's a good idea. The existing implementation of stream.scanf is a bit spotty anyway. You're welcome to use my code though the current implementation relies on a modified version of std.utf as well. I just merged recent updates to std.utf into the stdio.zip file I have on my website in case you want to use it. Sean
Jun 30 2005
In article <da27lu$2i9v$1 digitaldaemon.com>, Ben Hinkle says...Vathix's post on the bugs newsgroup about std.stream issue raised the topic of reading and converting text input to binary data like ints and floats and such. Currently std.stream has a scanf and vscanf that were written ages ago (probably before _argptr and _arguments existed) and I'd like to update them to the more modern D style much like Sean's unformat and/or readf.
Good idea! But doesn't streams support printf with old C syntax as well? For symmetry between the two, perhaps you should leave the old scanf as it is and call the new function readf() or something similar instead. That way it won't break any existing code, either. (Whether or not the old printf/scanf should be removed from stream altogether is another discussion :-) Nick
Jul 01 2005
"Nick" <Nick_member pathlink.com> wrote in message news:da3kbt$19j7$1 digitaldaemon.com...In article <da27lu$2i9v$1 digitaldaemon.com>, Ben Hinkle says...Vathix's post on the bugs newsgroup about std.stream issue raised the topic of reading and converting text input to binary data like ints and floats and such. Currently std.stream has a scanf and vscanf that were written ages ago (probably before _argptr and _arguments existed) and I'd like to update them to the more modern D style much like Sean's unformat and/or readf.
Good idea! But doesn't streams support printf with old C syntax as well? For symmetry between the two, perhaps you should leave the old scanf as it is and call the new function readf() or something similar instead. That way it won't break any existing code, either. (Whether or not the old printf/scanf should be removed from stream altogether is another discussion :-) Nick
That's possible but somehow I'd like to keep the name scanf since it's largely compatible with the existing scanf. Maybe to be unambiguous, though, the old scanf should be removed and the new one should be called readf and vreadf. I'd prefer not have both scanf and readf since the code involved is non-trivial (about 50-100 lines) while printf is a 5 line wrapper around C's sprintf and is more commonly used than scanf. Another argument in favor of readf is that if std.stdio ever gets a read-equivalent to writef it will probably be called readf to avoid name clashes with scanf. Hmm. I'm starting to swing over to readf.
Jul 01 2005
Ben Hinkle:That's possible but somehow I'd like to keep the name scanf since it's largely compatible with the existing scanf. Maybe to be unambiguous, though, the old scanf should be removed and the new one should be called readf and vreadf. I'd prefer not have both scanf and readf since the code involved is non-trivial (about 50-100 lines) while printf is a 5 line wrapper around C's sprintf and is more commonly used than scanf. Another argument in favor of readf is that if std.stdio ever gets a read-equivalent to writef it will probably be called readf to avoid name clashes with scanf. Hmm. I'm starting to swing over to readf.
I think readf goes nicely together with writef, as in "read" and "write" (but then I never liked the name scanf.) Also, it signals to C programmers that it is not a simple wrapper around the C scanf, but a entirely new function. Just my two cents. Nick
Jul 01 2005