Should D file end with newline?

Jonathan M Davis newsgroup.d at
Tue Feb 12 20:03:09 UTC 2019

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

More information about the Digitalmars-d-learn mailing list