Should D file end with newline?
sarn at theartofmachinery.com
Wed Feb 13 05:13:12 UTC 2019
On Tuesday, 12 February 2019 at 20:03:09 UTC, Jonathan M Davis
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
> 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.
More information about the Digitalmars-d-learn