Should D file end with newline?

[Jonathan M Davis]

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