Comment author: @alainfrisch

What's the rationale? Typically, maintaining deprecated definitions is relevant for library modules, and they should always have an explicit interface.

Comment author: @ygrek

they should always have an explicit interface.

This is it - sometimes they don't. Looks like an arbitrary limitation to me for the compiler to enforce this.

Comment author: @damiendoligez

I still think we should have demanded that every .ml have an explicit .mli.

This should be implemented if it's trivial, otherwise it's probably not worth the manpower.

Comment author: @alainfrisch

For type declarations, this is already supported: there is natural correspondence between structure items and generated signatures items. For value bindings, this is less clear: a single value binding (let (x, y) = ... [@@deprecated]) can generate multiple signature items (val x : ... val y : ...). One could declare that all these "val" sig items receive the same attributes as the let binding.

Perhaps the best way to support this would be to allow "val" declarations in structures (and keep attributes on those declarations for the corresponding signature items). It would also look nicer. Compare:

val foo: ...
[@@deprecated]
let foo x = ....
...
...
with:

let foo x = ...
...
...
[@@deprecated]

(this deprecated marker is far from "foo").

Comment author: @damiendoligez

What is the status of this after the merge of signature and structure items?

Comment author: @alainfrisch

I'm not convinced this is so useful. It's always possible to add even a local signature if needed to mark something as deprecated.

Comment author: @alainfrisch

Btw, there has been no merge of signature and structure items for now.