Should D file end with newline?

[sarn]

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.