On Mon, Aug 19, 2019 at 16:23:58 -0400, Tom Honermann wrote:
> I thought you and I had discussed the use case, but perhaps I'm mistaken.

I'm not recalling it off-hand, sorry. It is vaguely familiar, but
without some minutes, I don't remember any specific.

> The typical example where a BOM would be helpful is on non-ASCII systems
> like z/OS. If a BOM is allowed, then z/OS compilers could produce one
> to allow the contents to be more easily inspected by simple text
> viewing/editing tools. However, it may also be useful on Windows
> systems where a file viewer/editor that is not JSON aware (e.g., doesn't
> differentiate behavior for files with a .json extension) might otherwise
> interpret the file according to the Windows ACP.

The problem with allowing a BOM is that, AFAICT, most decoders don't
"just work" with it and the only one that hinted at how to do it right
was Python (with a new encoding!). Writers that I've seen *do* have a
flag for not writing a BOM (if they support writing it at all) however.

As for the extension, we use `.ddi` ("dyndep intermediate") in CMake for
these files right now, but the files are treated as an internal
implementation detail (but useful for debugging things).

--Ben