Add std.writeFile

[bnoordhuis]

std.loadFile already exists and is convenient. std.writeFile replaces the more onerous std.open + std.write + std.close idiom.

[chqrlie]

You might add that the string is encoded in UTF-8 on all systems, whereas the data from typed arrays or ArrayBuffer objects is simply written as untranslated binary data.

[bnoordhuis]

So, I'm not entirely sure that's correct. It uses fwrite and on Windows that's code page-dependent, AFAIK.

[chqrlie]

So, I'm not entirely sure that's correct. It uses fwrite and on Windows that's code page-dependent, AFAIK.

Indeed fwrite in Windows can do this, so if the stream is configured for code page or worse Unicode conversion, fwrite would unlikely produce gibberish output, aka Mojibake.

Here are the relevant paragraphs in the Microsoft help page:

The fwrite function writes up to count items, of size length each, from buffer to the output stream. The file pointer associated with stream (if there's one) is incremented by the number of bytes fwrite writes. If stream is opened in text mode, each line feed is replaced with a carriage return-line feed pair. The replacement has no effect on the return value.

When stream is opened in Unicode translation mode — for example, if stream is opened by calling fopen and using a mode parameter that includes ccs=UNICODE, ccs=UTF-16LE, or ccs=UTF-8, or if the mode is changed to a Unicode translation mode by using _setmode and a mode parameter that includes _O_WTEXT, _O_U16TEXT, or _O_U8TEXT — buffer is interpreted as a pointer to an array of wchar_t that contains UTF-16 data. An attempt to write an odd number of bytes in this mode causes a parameter validation error.

You open the file in default mode (text mode would use "wt") so the stream translation mode will be the default translation mode defined by the global variable _fmode which could be _O_TEXT and trigger LF to CR/LF translation or _O_BINARY which would leave the output unchanged.

Unless I am missing some more subtle side effects, the data written should just undergo line ending translation.

My suggestion is correct for unix-like systems and somewhat helpful, albeit UTF-8 is probably expected on these systems, and a more explicit caveat for Windows could help programmers who set up the standard streams stdout or stderr to perform code page or Unicode translation.