Should D file end with newline?

[Jacob Carlborg]

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.

-- 
/Jacob Carlborg