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

Should D file end with newline, too?

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.

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

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.

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.

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

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

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

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.

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.