OCaml warns there is a .ml file but no .mli. Globally, this new warning proved useful, but there are two common cases I am not quite sure how to handle:
The .ml file is a pure interface file (i.e., the .mli file would be a verbatim copy of it), so it does not make much sense to duplicate it just to silence the warning.
The .mli file would be empty. So, the warning fulfills its purpose. But it would be better if there was a way to inform the compiler without having to put empty .mli files all over the place (e.g., about 50 dummy files for Why3).
Obviously, I can fix both issues at the level of the build system. But I would be interested in a way for the .ml files to be self-documenting. For example, putting [@@@warning "-70"] does not seem to have any effect.
For the first case, the compiler and most build systems support .mli-only modules. The main issue is that dune doesn’t seem to handle them very well, although I’ve never understood exactly why (I’ve read the issue on the dune side, and they seem to think it’s a compiler issue, which is clearly not the case as it works with all other build systems).
What the… More than twenty years of OCaml and that is the first time I am hearing of it. Time to rename some files. Thanks.
As for [@@@warning "-70"], it was meant to deal with the first case. For the second case, I would rather have [@@@empty-signature] or something. (But it still fits the “unit header” thing, so the RFC you pointed out is relevant.)
As far as I can tell, dune seems quite happy with .mli-only modules as soon as we take care to list them in the (modules_without_implementation ...) section of the executable or library stanza (and if we forget to do so, dune reminds us to do it anyway).