On 03/16/2011 07:54 AM, Ali Çehreli wrote:
> On 03/16/2011 05:49 AM, Kagamin wrote:
>> Ali ǥhreli Wrote:
>>
>>> The following program may be surprising to the novice:
>>>
>>> import std.stdio;
>>>
>>> void main()
>>> {
>>> write("What is your name? ");
>>> string name = readln();
>>> writeln("Hi ", name, "!");
>>> }
>>
>> What if the user typed leading spaces? Will the program operate as you
>> expect?
>
> I would not like the leading spaces either, and that's another issue:
> contrary to readln(), readf() leaves the newline character in the input.
> I was about to start adopting the guideline of using " %s" (note the
> space) when reading formatted unless there is a reason not to. Most of
> the time the newline left from the previous input has nothing to do with
> the next read.
>
> Otherwise the following program gets stuck:
>
> import std.stdio;
>
> void main()
> {
> int i, j;
> readf("%s%s", &i, &j);
> }
>
> As a result, my current guideline is "put a space before every format
> specifier":
>
> readf(" %s %s", &i, &j);
>
> This is a departure from C's scanf but is more consistent.
>
> I don't want to accept and teach buggy behavior and that's why I asked
> on the D forum. Unfortunately I failed to attract interest there.
>
> After accepting the above, I wanted to readf() lines too:
>
> import std.stdio;
>
> void main()
> {
> string s;
> readf(" %s", &s);
> writeln(s);
> }
>
> As another departure from C, readf() does not stop at the first
> whitespace. It reads until the end of the input. Ok, I like that
> behavior but it's not useful for "What is your name? " like inputs.
>
> So it led me to readln().
>
> I don't have a problem with whitespace being left in the line, I just
> want to know whether that's the intended or accepted behavior.
>
> Ali

I think there are two issues here. First, I think is perfectly reasonable to let the programmer use a simple mechanism like "string.chomp(stdin.readline())" or simply "chomp(readln())" when they don't want the new line.

Second, D doesn't seem to have a graceful way of reading an endless stream of <your favorite data type> delimited by <your favorite delimiting character>. I think readf is rigid, and works great in some cases. I would greatly appreciate something more flexible like C++'s extraction operator (operator>>) though. For example:
int i = 0;
while(cin >> i)
{
    //Do something
}
// Done doing something

Kai Meyer Wrote:

> Second, D doesn't seem to have a graceful way of reading an endless stream of <your favorite data type> delimited by <your favorite delimiting character>. I think readf is rigid, and works great in some cases. I would greatly appreciate something more flexible like C++'s extraction operator (operator>>) though. For example:

There is interest in getting a CSV parser in D. Of which I was hoping to be able to make use of a ForwardRange with Slicing... but could not find a way turn a buffered input range into a forward range. This made my second attempt useless for input ranges.

https://github.com/he-the-great/JPDLibs/tree/csv

https://github.com/he-the-great/JPDLibs/tree/separator

The benefit of the second is that you can using string to make a separator, or would be if startsWith worked as I want. But started working on the first to make it closer to what should be available in the standard library.

Am 16.03.2011 11:09, schrieb spir:
> This is a design bug. 99% of the time one does not want the newline,
> which is not part of the string data, instead just a terminator. Even
> more on stdin where it is used by the user to say "I"m done!".
> If the text is written back to the output /and/ newline is needed,
> it's easy to add it or use writeln.
>
This is a very interesting statement and absolute contrary to my experience. I think It is never a design bug  for
a standart function to forward as much information as possible. Suppressing unwanted information is very easy,
but getting back some information that has been cut off by a courteous tool is an awful job.
That data comes in via stdin doesn't mean is is typed in by the user. It's perfectly possible that it is piped in and
 that the line endings should not be touched. You must be a very lucky person if you have never been bitten by
such a courteous piece of over engineered software.

I hope you can continue being lucky for a long time. :-)

Gerrit