• Victor Porton (2/2) Feb 09 2019 ISO C++ specifies that the C++ file must end with a newline.
• sarn (4/6) Feb 09 2019 I'm sure you could mostly get away without one, but POSIX says
• Jonathan M Davis (12/14) Feb 09 2019 No, there is no need to end D files with a newline. I would guess that t...
• Cym13 (6/23) Feb 10 2019 If you used a text editor or IDE to write that final closing
• Jonathan M Davis (45/71) Feb 10 2019 I use (g)vim, which I would expect to show anything like trailing newlin...
• Jacob Carlborg (14/62) Feb 12 2019 According to my text editor (TextMate) and GitHub* both
• Jonathan M Davis (23/87) Feb 12 2019 I don't know. The various programs don't seem to agree what's actually i...
• sarn (19/35) Feb 12 2019 On Tuesday, 12 February 2019 at 20:03:09 UTC, Jonathan M Davis
• Patrick Schluter (10/47) Feb 15 2019 A lots of fgets() based tools on Unix systems fail to read the
• sarn (3/12) Feb 16 2019 That makes sense. I guess I'm spoiled by GNU.
• Benjamin Schaaf (8/25) Feb 10 2019 Doing a quick a quick tail on all the source files for dmd,

Victor Porton <porton narod.ru> writes:

ISO C++ specifies that the C++ file must end with a newline.

Should D file end with newline, too?

sarn <sarn theartofmachinery.com> writes:

On Saturday, 9 February 2019 at 21:19:27 UTC, Victor Porton wrote:
 ISO C++ specifies that the C++ file must end with a newline.

 Should D file end with newline, too?

I'm sure you could mostly get away without one, but POSIX says 
that all text files should end with a newline.  There are some 
POSIX tools that don't work properly without the final newline.

Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:

On Saturday, February 9, 2019 2:19:27 PM MST Victor Porton via Digitalmars-
d-learn wrote:
 ISO C++ specifies that the C++ file must end with a newline.

 Should D file end with newline, too?

No, there is no need to end D files with a newline. I would guess that the
vast majority of D files end with a closing brace. I just looked at a bunch
of files in the standard library for the heck of it, and almost all of the
ones I looked at ended with a closing brace. And those that didn't ended
with something like an enum declaration and not a newline. Personally, I
don't leave newlines at the end of files, because it looks messy. I don't
even recall doing that in C++, though I do recall that there supposedly be a
rule about it. It seems like a pretty bizarre requirement to me, but
regardless, I'm quite sure that D does not have that requirement.

- Jonathan M Davis

Cym13 <cpicard openmailbox.org> writes:

On Sunday, 10 February 2019 at 02:12:43 UTC, Jonathan M Davis 
wrote:
 On Saturday, February 9, 2019 2:19:27 PM MST Victor Porton via 
 Digitalmars- d-learn wrote:
 ISO C++ specifies that the C++ file must end with a newline.

 Should D file end with newline, too?

 No, there is no need to end D files with a newline. I would 
 guess that the vast majority of D files end with a closing 
 brace. I just looked at a bunch of files in the standard 
 library for the heck of it, and almost all of the ones I looked 
 at ended with a closing brace. And those that didn't ended with 
 something like an enum declaration and not a newline. 
 Personally, I don't leave newlines at the end of files, because 
 it looks messy. I don't even recall doing that in C++, though I 
 do recall that there supposedly be a rule about it. It seems 
 like a pretty bizarre requirement to me, but regardless, I'm 
 quite sure that D does not have that requirement.

 - Jonathan M Davis

If you used a text editor or IDE to write that final closing 
brace then I'm pretty confident it does add the newline character 
at the end. That won't result in an empty line on display. Try 
using an hex editor to check if you're curious.

Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:

On Sunday, February 10, 2019 2:06:50 AM MST Cym13 via Digitalmars-d-learn 
wrote:
 On Sunday, 10 February 2019 at 02:12:43 UTC, Jonathan M Davis

 wrote:
 On Saturday, February 9, 2019 2:19:27 PM MST Victor Porton via

 Digitalmars- d-learn wrote:
 ISO C++ specifies that the C++ file must end with a newline.

 Should D file end with newline, too?

 No, there is no need to end D files with a newline. I would
 guess that the vast majority of D files end with a closing
 brace. I just looked at a bunch of files in the standard
 library for the heck of it, and almost all of the ones I looked
 at ended with a closing brace. And those that didn't ended with
 something like an enum declaration and not a newline.
 Personally, I don't leave newlines at the end of files, because
 it looks messy. I don't even recall doing that in C++, though I
 do recall that there supposedly be a rule about it. It seems
 like a pretty bizarre requirement to me, but regardless, I'm
 quite sure that D does not have that requirement.

 - Jonathan M Davis

 If you used a text editor or IDE to write that final closing
 brace then I'm pretty confident it does add the newline character
 at the end. That won't result in an empty line on display. Try
 using an hex editor to check if you're curious.

I use (g)vim, which I would expect to show anything like trailing newlines.
It usually shows everything, including rendering control characters and the
like in a way that you know exactly what's there. Opening up
std/algorithm/mutation.d in vim as an example, it clearly ends in a closing
brace with no trailing newline. However if I feed it into hexdump

...
00158f0 2020 6373 706f 2865 7865 7469 2029 7266
0015900 6565 7328 702e 7274 3b29 7d0a 000a
001590d

hexdump shows a newline followed by a null character followed by a newline
after the carriage return. So, it does indeed look like extra junk is there
after the data in the file, and surprisingly, vim doesn't showing it (or
anything indicating that it's there). I don't know why any of that would be
there, since it seems pointless me, but it is there in
std/algorithm/mutation.d. On the other hand, if I open up
std/datetime/systime.d with hexdump, it shows

007f8b0 0a7d 2020 2020 2020 2020 0a7d 2020 2020
007f8c0 0a7d 0a7d
007f8c4

so it actually ends on a closing braces. So, maybe some text editors shove
extra junk on the end and others don't? I don't know. Either way, I find it
very odd that vim doesn't show anything after the closing brace when it's
there. Both of those files show a closing brace as their last character when
opened in vim. Looking quickly at some of my personal projects, I don't see
any files which end with anything other than a closing brace according to
either vim or hexdump. And since all of those were created with (g)vim, I'd
say that vim does not put those extra characters on the end (though it will
allow them and otherwise ignore them). That also makes it clear that no
newline or any other special sequence of characters is required at the end
of a .d file, because all of those files work just fine with their last
character being a closing brace.

Curiously, if I create a .cpp or .c file with vim and have it end with a
curly brace, vim _does_ append a newline followed by a null character
followed by a newline at the end of the file. So, I guess that vim looks at
the extension and realizes that C/C++ has such a requirement and takes care
of it for you, but it does not think that .d files need them and adds
nothing extra for them. It doesn't add anything for a .txt file when I tried
it either.

In any case, if your text editor happens to insert those extra characters at
the end of a .d file, then they may end up there, but given what hexdump
says and what dmd accepts, I can verify that they aren't actually required
for .d files.

- Jonathan M Davis

Jacob Carlborg <doob me.com> writes:

On 2019-02-10 18:20, Jonathan M Davis wrote:

 I use (g)vim, which I would expect to show anything like trailing newlines.
 It usually shows everything, including rendering control characters and the
 like in a way that you know exactly what's there. Opening up
 std/algorithm/mutation.d in vim as an example, it clearly ends in a closing
 brace with no trailing newline. However if I feed it into hexdump
 
 ...
 00158f0 2020 6373 706f 2865 7865 7469 2029 7266
 0015900 6565 7328 702e 7274 3b29 7d0a 000a
 001590d
 
 hexdump shows a newline followed by a null character followed by a newline
 after the carriage return. So, it does indeed look like extra junk is there
 after the data in the file, and surprisingly, vim doesn't showing it (or
 anything indicating that it's there). I don't know why any of that would be
 there, since it seems pointless me, but it is there in
 std/algorithm/mutation.d. On the other hand, if I open up
 std/datetime/systime.d with hexdump, it shows
 
 007f8b0 0a7d 2020 2020 2020 2020 0a7d 2020 2020
 007f8c0 0a7d 0a7d
 007f8c4
 
 so it actually ends on a closing braces. So, maybe some text editors shove
 extra junk on the end and others don't? I don't know. Either way, I find it
 very odd that vim doesn't show anything after the closing brace when it's
 there. Both of those files show a closing brace as their last character when
 opened in vim. Looking quickly at some of my personal projects, I don't see
 any files which end with anything other than a closing brace according to
 either vim or hexdump. And since all of those were created with (g)vim, I'd
 say that vim does not put those extra characters on the end (though it will
 allow them and otherwise ignore them). That also makes it clear that no
 newline or any other special sequence of characters is required at the end
 of a .d file, because all of those files work just fine with their last
 character being a closing brace.
 
 Curiously, if I create a .cpp or .c file with vim and have it end with a
 curly brace, vim _does_ append a newline followed by a null character
 followed by a newline at the end of the file. So, I guess that vim looks at
 the extension and realizes that C/C++ has such a requirement and takes care
 of it for you, but it does not think that .d files need them and adds
 nothing extra for them. It doesn't add anything for a .txt file when I tried
 it either.
 
 In any case, if your text editor happens to insert those extra characters at
 the end of a .d file, then they may end up there, but given what hexdump
 says and what dmd accepts, I can verify that they aren't actually required
 for .d files.

According to my text editor (TextMate) and GitHub* both 
std/algorithm/mutation.d and std/datetime/systime.d ends with a newline. 
Also all your source files in your dxml project ends with a newline. 
Using "cat" to show the content of a file it's pretty clear if it ends 
with a newline or not. If it doesn't, then the prompt will be printed 
after the last character in the file. If it does end with a newline, the 
prompt will be printed on its own line. (Some terminal emulators, like 
iTerm, will add a newline automatically before printing the prompt if 
the last output doesn't end with a newline).

* GitHub will add a symbol at the end of the file indicating it doesn't 
end with a newline.

-- 
/Jacob Carlborg

Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:

On Tuesday, February 12, 2019 4:45:43 AM MST Jacob Carlborg via Digitalmars-
d-learn wrote:
 On 2019-02-10 18:20, Jonathan M Davis wrote:
 I use (g)vim, which I would expect to show anything like trailing
 newlines. It usually shows everything, including rendering control
 characters and the like in a way that you know exactly what's there.
 Opening up
 std/algorithm/mutation.d in vim as an example, it clearly ends in a
 closing brace with no trailing newline. However if I feed it into
 hexdump

 ...
 00158f0 2020 6373 706f 2865 7865 7469 2029 7266
 0015900 6565 7328 702e 7274 3b29 7d0a 000a
 001590d

 hexdump shows a newline followed by a null character followed by a
 newline after the carriage return. So, it does indeed look like extra
 junk is there after the data in the file, and surprisingly, vim doesn't
 showing it (or anything indicating that it's there). I don't know why
 any of that would be there, since it seems pointless me, but it is
 there in
 std/algorithm/mutation.d. On the other hand, if I open up
 std/datetime/systime.d with hexdump, it shows

 007f8b0 0a7d 2020 2020 2020 2020 0a7d 2020 2020
 007f8c0 0a7d 0a7d
 007f8c4

 so it actually ends on a closing braces. So, maybe some text editors
 shove extra junk on the end and others don't? I don't know. Either way,
 I find it very odd that vim doesn't show anything after the closing
 brace when it's there. Both of those files show a closing brace as
 their last character when opened in vim. Looking quickly at some of my
 personal projects, I don't see any files which end with anything other
 than a closing brace according to either vim or hexdump. And since all
 of those were created with (g)vim, I'd say that vim does not put those
 extra characters on the end (though it will allow them and otherwise
 ignore them). That also makes it clear that no newline or any other
 special sequence of characters is required at the end of a .d file,
 because all of those files work just fine with their last character
 being a closing brace.

 Curiously, if I create a .cpp or .c file with vim and have it end with a
 curly brace, vim _does_ append a newline followed by a null character
 followed by a newline at the end of the file. So, I guess that vim looks
 at the extension and realizes that C/C++ has such a requirement and
 takes care of it for you, but it does not think that .d files need them
 and adds nothing extra for them. It doesn't add anything for a .txt
 file when I tried it either.

 In any case, if your text editor happens to insert those extra
 characters at the end of a .d file, then they may end up there, but
 given what hexdump says and what dmd accepts, I can verify that they
 aren't actually required for .d files.

 According to my text editor (TextMate) and GitHub* both
 std/algorithm/mutation.d and std/datetime/systime.d ends with a newline.
 Also all your source files in your dxml project ends with a newline.
 Using "cat" to show the content of a file it's pretty clear if it ends
 with a newline or not. If it doesn't, then the prompt will be printed
 after the last character in the file. If it does end with a newline, the
 prompt will be printed on its own line. (Some terminal emulators, like
 iTerm, will add a newline automatically before printing the prompt if
 the last output doesn't end with a newline).

 * GitHub will add a symbol at the end of the file indicating it doesn't
 end with a newline.

I don't know. The various programs don't seem to agree what's actually in
the file. If you want another test though, I tried writing a program that
wrote out a hello world program with no newlines in it. I never opened the
resulting file it in a text editor, so no text editor could screw with it,
and it compiled and ran with dmd just fine. cat even doesn't print any
newlines in my terminal when cat-ing, screwing up the prompt, since it's not
on its own line. So, I'd say that it's safe to say that dmd does not care
about newlines at the end of the file, and I honestly have no clue why any
programming language would unless C/C++ is doing something like relying on
the newline at the end of the file to make sure #including files results in
whitespace between them, but AFAIK, you have to put #includes on their own
line anyway, and even if that _were_ the problem, the compiler could have
just inserted the newlines. The whole thing just seems like a weird
requirement that really shouldn't be there, but given that it's C/C++, there
was probably something weird with computers back in the 1970's that made it
seem like a better idea than it seems like now. Regardless, none of that
applies to D, and it matters even less if text editors are automatically
appending newlines to files if they aren't there whether they show them or
not, since if that's the case, you'd have to really work at it to have files
not ending with newlines anyway.

- Jonathan M Davis

sarn <sarn theartofmachinery.com> writes:

On Tuesday, 12 February 2019 at 20:03:09 UTC, Jonathan M Davis 
wrote:
So, I'd say that it's safe to say that dmd
 The whole thing just seems like a weird requirement that really 
 shouldn't be there,

Like I said in the first reply, FWIW, it's a POSIX requirement.

Turns out most tools don't care (and dmd is apparently one of 
them).  If you want an easy counterexample, try the wc command 
(it miscounts lines for non-compliant files).  I've never seen 
that break an actual build system, which is why I said you could 
mostly get away with it.  On the other hand, being 
POSIX-compliant always works.

 it matters even less if text editors are automatically 
 appending newlines to files if they aren't there whether they 
 show them or not, since if that's the case, you'd have to 
 really work at it to have files not ending with newlines anyway.

There are definitely broken text editors out there that won't add 
the newline (can't think of names).  Like Jacob Carlborg said, 
Github flags the files they generate.

 hexdump shows a newline followed by a null character followed 
 by a newline after the carriage return.

hexdump is printing little-endian 16b by default, so I think 
that's just two newlines followed by a padding byte from hexdump. 
  Try using the -c or -b flag and you probably won't see any null 
byte.

 Curiously, if I create a .cpp or .c file with vim and have it 
 end with a curly brace, vim _does_ append a newline followed by 
 a null character followed by a newline at the end of the file. 
 So, I guess that vim looks at the extension and realizes that 
 C/C++ has such a requirement and takes care of it for you, but 
 it does not think that .d files need them and adds nothing 
 extra for them. It doesn't add anything for a .txt file when I 
 tried it either.

Are you sure?  vim is supposed to add the newline for all text 
files because that's POSIX.  It does on my (GNU/Linux) machine.

Patrick Schluter <Patrick.Schluter bbox.fr> writes:

On Wednesday, 13 February 2019 at 05:13:12 UTC, sarn wrote:
 On Tuesday, 12 February 2019 at 20:03:09 UTC, Jonathan M Davis 
 wrote:
 So, I'd say that it's safe to say that dmd
 The whole thing just seems like a weird requirement that 
 really shouldn't be there,

 Like I said in the first reply, FWIW, it's a POSIX requirement.

 Turns out most tools don't care (and dmd is apparently one of 
 them).  If you want an easy counterexample, try the wc command 
 (it miscounts lines for non-compliant files).  I've never seen 
 that break an actual build system, which is why I said you 
 could mostly get away with it.  On the other hand, being 
 POSIX-compliant always works.

 it matters even less if text editors are automatically 
 appending newlines to files if they aren't there whether they 
 show them or not, since if that's the case, you'd have to 
 really work at it to have files not ending with newlines 
 anyway.

 There are definitely broken text editors out there that won't 
 add the newline (can't think of names).  Like Jacob Carlborg 
 said, Github flags the files they generate.

 hexdump shows a newline followed by a null character followed 
 by a newline after the carriage return.

 hexdump is printing little-endian 16b by default, so I think 
 that's just two newlines followed by a padding byte from 
 hexdump.
  Try using the -c or -b flag and you probably won't see any 
 null byte.

 Curiously, if I create a .cpp or .c file with vim and have it 
 end with a curly brace, vim _does_ append a newline followed 
 by a null character followed by a newline at the end of the 
 file. So, I guess that vim looks at the extension and realizes 
 that C/C++ has such a requirement and takes care of it for 
 you, but it does not think that .d files need them and adds 
 nothing extra for them. It doesn't add anything for a .txt 
 file when I tried it either.

 Are you sure?  vim is supposed to add the newline for all text 
 files because that's POSIX.  It does on my (GNU/Linux) machine.

A lots of fgets() based tools on Unix systems fail to read the 
last line if it doesn't contain a line feed character at the end. 
Afaicr glibc implementation does not have that problem but a lot 
of other standard C libs do.
When we were still on Solaris we had to be very careful with 
that, as strange things could happen when using sed, awk, wc and 
a lot of other standard Unix commands.
Now that we have switched to Linux we don't have the issue 
anymore.

sarn <sarn theartofmachinery.com> writes:

On Friday, 15 February 2019 at 13:14:47 UTC, Patrick Schluter 
wrote:
 A lots of fgets() based tools on Unix systems fail to read the 
 last line if it doesn't contain a line feed character at the 
 end. Afaicr glibc implementation does not have that problem but 
 a lot of other standard C libs do.
 When we were still on Solaris we had to be very careful with 
 that, as strange things could happen when using sed, awk, wc 
 and a lot of other standard Unix commands.
 Now that we have switched to Linux we don't have the issue 
 anymore.

That makes sense.  I guess I'm spoiled by GNU.

Benjamin Schaaf <ben.schaaf gmail.com> writes:

On Sunday, 10 February 2019 at 02:12:43 UTC, Jonathan M Davis 
wrote:
 On Saturday, February 9, 2019 2:19:27 PM MST Victor Porton via 
 Digitalmars- d-learn wrote:
 ISO C++ specifies that the C++ file must end with a newline.

 Should D file end with newline, too?

 No, there is no need to end D files with a newline. I would 
 guess that the vast majority of D files end with a closing 
 brace. I just looked at a bunch of files in the standard 
 library for the heck of it, and almost all of the ones I looked 
 at ended with a closing brace. And those that didn't ended with 
 something like an enum declaration and not a newline. 
 Personally, I don't leave newlines at the end of files, because 
 it looks messy. I don't even recall doing that in C++, though I 
 do recall that there supposedly be a rule about it. It seems 
 like a pretty bizarre requirement to me, but regardless, I'm 
 quite sure that D does not have that requirement.

 - Jonathan M Davis

Doing a quick a quick tail on all the source files for dmd, 
druntime and phobos, I only found 6 source files that ended in a 
curly brace and 2 ending in a 'g'. All others ended with a 
newline. Its certainly not required but it is common in the style 
guides I've seen and I personally have my editor automatically 
insert a newline.