On Monday, 30 December 2013 at 03:03:37 UTC, Marco Leise wrote:
> Am Sat, 28 Dec 2013 17:08:38 +0000
> schrieb "Vladimir Panteleev" <vladimir@thecybershadow.net>:
>
>> On Saturday, 28 December 2013 at 17:07:23 UTC, Andrei Alexandrescu wrote:
>> > On 12/28/13 8:49 AM, Jeroen Bollen wrote:
>> >> Why is when you do readln() the newline character (\n) gets read too?
>> >> Wouldn't it make more sense for that character to be stripped off?
>> >
>> > So you know that if it returns an empty string the file is done.
>> 
>> And also so a readln/writeln loop preserves line endings.
>
> Detect the bug in this sentence.

:)

Spoiler: readln/write *

On Sat, 28 Dec 2013 17:42:23 -0000, Jakob Ovrum <jakobovrum@gmail.com> wrote:

> On Saturday, 28 December 2013 at 17:23:30 UTC, Jeroen Bollen wrote:
>> Usually if you're working with a console though the input stream won't exhaust and thus the blocking 'readln' would be a better option, no?
>
> The blocking behaviour of `stdin` by default is fine. The issue is that `readln` returns an empty string when `stdin` is empty/closed, which is different from an empty line (which is just the line terminator). Approaches that erase the difference with functions like `chomp` can't tell them apart.

Cue "empty vs null" theme music..

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On Monday, 30 December 2013 at 12:36:15 UTC, Regan Heath wrote:
> Cue "empty vs null" theme music..

Empty vs null is not a factor here. It returns a string containing the line terminator(s) for an empty line, but an empty string (incidentally non-null) if the file is closed.

On Mon, 30 Dec 2013 13:51:46 -0000, Jakob Ovrum <jakobovrum@gmail.com> wrote:

> On Monday, 30 December 2013 at 12:36:15 UTC, Regan Heath wrote:
>> Cue "empty vs null" theme music..
>
> Empty vs null is not a factor here. It returns a string containing the line terminator(s) for an empty line, but an empty string (incidentally non-null) if the file is closed.

Yes .. but it /could/ have returned null for file closed and /an empty line/ for /an empty line/ .. what an idea!  Then the readln/writeln <- whoops bug "problem" vanishes too, bonus!

Nevermind.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On Monday, 30 December 2013 at 02:59:23 UTC, Marco Leise wrote:
> Am Sun, 29 Dec 2013 22:03:14 +0000
> schrieb "Jeroen Bollen" <jbinero@gmail.com>:
>
>> On Sunday, 29 December 2013 at 18:13:30 UTC, Jakob Ovrum wrote:
>> > On Sunday, 29 December 2013 at 17:25:39 UTC, Jeroen Bollen wrote:
>> >> Wouldn't byline return an empty string if the inputstream is exhausted but not closed?
>> >
>> > No, both `readln` and `byLine` will block until either EOL or EOF. They differ in their handling of EOF - `readln` returns an empty string, while the result of `byLine` reports empty (it is a range) and calling `front` is an error.
>> 
>> But wouldn't that mean I'd still end up making my char[] mutable, as I still need to manually remove the last character, AFTER I checked it's not empty?
>
> No, strings have immutable characters, but there is nothing
> wrong with using only part of it as an array slice:
>
>   string s = readln();
>   s = s[0 .. $-1];
>
> (just to illustrate)
I'm not talking about string though, I know you can resize a string, as it's an alias for immutable(char)[], but an immutable string would be immutable(immutable(char)[]), which is an immutable(charr[]). A mutable string would be immutable(char)[] which is the problem! Why does it need to be mutable if it won't ever change anyway!

Am Tue, 31 Dec 2013 13:09:34 +0000
schrieb "Jeroen Bollen" <jbinero@gmail.com>:

> On Monday, 30 December 2013 at 02:59:23 UTC, Marco Leise wrote:
> > Am Sun, 29 Dec 2013 22:03:14 +0000
> > schrieb "Jeroen Bollen" <jbinero@gmail.com>:
> >
> >> On Sunday, 29 December 2013 at 18:13:30 UTC, Jakob Ovrum wrote:
> >> > On Sunday, 29 December 2013 at 17:25:39 UTC, Jeroen Bollen wrote:
> >> >> Wouldn't byline return an empty string if the inputstream is exhausted but not closed?
> >> >
> >> > No, both `readln` and `byLine` will block until either EOL or EOF. They differ in their handling of EOF - `readln` returns an empty string, while the result of `byLine` reports empty (it is a range) and calling `front` is an error.
> >> 
> >> But wouldn't that mean I'd still end up making my char[] mutable, as I still need to manually remove the last character, AFTER I checked it's not empty?
> >
> > No, strings have immutable characters, but there is nothing wrong with using only part of it as an array slice:
> >
> >   string s = readln();
> >   s = s[0 .. $-1];
> >
> > (just to illustrate)
> I'm not talking about string though, I know you can resize a string, as it's an alias for immutable(char)[], but an immutable string would be immutable(immutable(char)[]), which is an immutable(charr[]). A mutable string would be immutable(char)[] which is the problem! Why does it need to be mutable if it won't ever change anyway!

I guess I just don't see what an immutable string buys you. The mutable part in a string is just a pointer and length pair. Just write:

  immutable s = readln()[0 .. $-1];

and you have an immutable string at no cost.

-- 
Marco

On 31/12/2013 14:45, Marco Leise wrote:
<snip>
> I guess I just don't see what an immutable string buys you.
> The mutable part in a string is just a pointer and length pair.
> Just write:
>
>    immutable s = readln()[0 .. $-1];
>
> and you have an immutable string at no cost.

What if the line is at EOF and doesn't have a trailing newline?  Then surely you would lose the final byte of the input.

Moreover, does readln normalise the line break style (CR/LF/CRLF)?

I'd be inclined to define a function like

string stripLineBreak(string s) {
    while (s.length != 0 && s[$-1] != '\n' && s[$-1] != '\r') {
        s = s[0..$-1];
    }
    return s;
}

Stewart.

Am Tue, 31 Dec 2013 16:21:14 +0000
schrieb Stewart Gordon <smjg_1998@yahoo.com>:

> On 31/12/2013 14:45, Marco Leise wrote:
> <snip>
> > I guess I just don't see what an immutable string buys you. The mutable part in a string is just a pointer and length pair. Just write:
> >
> >    immutable s = readln()[0 .. $-1];
> >
> > and you have an immutable string at no cost.
> 
> What if the line is at EOF and doesn't have a trailing newline?  Then surely you would lose the final byte of the input.

That line of code was out of context. Of course you have to check for the correct line ending character(s) or use a more general tailing white-space removal function.

> Moreover, does readln normalise the line break style (CR/LF/CRLF)?

No it doesn't. It gives you verbatim input.

> I'd be inclined to define a function like
> 
> string stripLineBreak(string s) {
>      while (s.length != 0 && s[$-1] != '\n' && s[$-1] != '\r') {
>          s = s[0..$-1];
>      }
>      return s;
> }
> 
> Stewart.

And what happens when you use readln() on a system where the terminal character encoding is not UTF-8 and you type e.g. ä? I feel inclined to write a whole new std.terminal!

-- 
Marco

Stewart Gordon:

> I'd be inclined to define a function like
>
> string stripLineBreak(string s) {
>     while (s.length != 0 && s[$-1] != '\n' && s[$-1] != '\r') {
>         s = s[0..$-1];
>     }
>     return s;
> }

See the chop and chomp functions in std.string.

Bye,
bearophile

On 28/12/2013 16:49, Jeroen Bollen wrote:
> Why is when you do readln() the newline character (\n) gets read too?
> Wouldn't it make more sense for that character to be stripped off?

The newline character needs to be read - how else will it know when it's got to the end of the line? :)

Of course, that doesn't mean that it needs to be included in the string returned by readln.  Indeed, this is an inconsistency - writeln adds a newline so, in order to match, readln ought to strip the newline away.

But sometimes you might want the newline.  Maybe you're building up a string in memory from several lines, or you want to know whether the file ends with a newline or not.  Indeed, there are three possibilities:

- you don't care about the newlines themselves, only the strings they delimit
- you care about the presence or absence of a final newline
- you want to preserve the distinction between different styles of newline (CR, LF, CRLF, whatever else).

Maybe readln should have an optional parameter so that you have the choice.

Stewart.