Comment author: @nojb

Related PR: #1822

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

This bug is still present and relevant.

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

The people who have looked most at alerts and warnings, and might look at this, are @alainfrisch and @lpw25. i don't know if other contributors ( @antalsz, @nchataing, @Drup ) would be interested in looking at it.

After some investigation, what comes clear is the fact that let f = (fun x -> x) [@@deprecated] puts the attribute on the value binding (see https://github.com/ocaml/ocaml/blob/trunk/typing/typedtree.ml#L296); however if we want the deprecated warning to fire, we need an attribute on the pattern inside the value binding (which would roughly correspond to Tpat_var "f" in this case).

The following code will hence emit the desired warning : let f[@deprecated] = fun x -> x in f 0.

After some thinking, one possible fix would be to propagate the deprecated attributes of a value binding inside its pattern, but it seems overly complicated (and it would certainly make typecore and typemod more complicated to follow).

In let x,y = (1, 2) [@@deprecated], which of x or yshould be marked as deprecated? I guess, both, but this shows pushing the alert from the whole binding to individual variables is not very natural.

As @nchataing mentioned, there is a syntax which works, and I'm tempted to believe that marking some components as deprecated within an implementation is rare enough (I've only seen case of deprecation markers in module signatures), so I'm not sure something needs to be fixed.

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.