Should D file end with newline?

[Patrick Schluter]

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.