www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Should D file end with newline?

reply 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?
Feb 09 2019
next sibling parent 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.
Feb 09 2019
prev sibling parent reply 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
Feb 09 2019
next sibling parent reply 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.
Feb 10 2019
parent reply 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
Feb 10 2019
parent reply 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
Feb 12 2019
parent reply 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
Feb 12 2019
parent reply 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.
Feb 12 2019
parent reply 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.
Feb 15 2019
parent 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.
Feb 16 2019
prev sibling parent 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.
Feb 10 2019