You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Original bug ID: 7005 Reporter:@paurkedal Assigned to:@alainfrisch Status: resolved (set by @alainfrisch on 2017-07-18T12:13:13Z) Resolution: won't fix Priority: normal Severity: tweak Target version: 4.06.0 +dev/beta1/beta2/rc1 Category: typing Monitored by:@gasche@diml@hcarty
Bug description
When deprecating a recursive type, the definition itself triggers the warning. While this could server to remind the library writer to remove the definition later, I think it is more of a nuisance since the deprecation period may be long, and it is inconsistent with non-recursive type definitions and value definitions.
Steps to reproduce
type t = Z | S of t [@@ocaml.deprecated "Only for bug report."];;
Additional information
Tested with ocaml 4.02.3 and ocaml master checkout 2015-10-03.
The text was updated successfully, but these errors were encountered:
I wonder if there isn't a deeper problem. Usually, if a deprecated type is exposed, operations working on it will also be exposed and be marked as deprecated, as in:
type t = ..... [@@ocaml.deprecated]
val f: t -> unit [@@ocaml.deprecated]
In such cases, the reference to t in "val f:..." will also trigger the warning when compiling the interface.
Fixing only the reported issue would have the effect that:
type t = int [@@ocaml.deprecated]
and s = A of t
would not trigger the warning while:
type t = int [@@ocaml.deprecated]
type s = A of t
would trigger it, which does not looks right.
A different direction would be to consider that all deprecation warnings apply only outside the signature where they appear, not when processing subsequent declarations in the same signature. I.e. deprecation markers are not kept in the type-checking environment (used for later signature items) but only in the synthesized signature.
Cf discussion on #1237. I reached the conclusion that there is no reason to special case self-references. Other heuristics were considered ((i) make the deprecated warning visible only outside the current signature/structure; (ii) automatically disable deprecation warning when processing a deprecated declaration) but rejected for now.
Instead, I've opened #1248 to allow a finer control of warning settings, including within type expressions, and, in fact, everywhere an attribute is allowed (with the natural scope). So it becomes straightforward, if needed, to disable warning 3 at the same time that marking a declaration as deprecated, as in:
type t = A of t | B of t * t | C
[@@ocaml.deprecated]
[@@ocaml.warning "-3"]
Original bug ID: 7005
Reporter: @paurkedal
Assigned to: @alainfrisch
Status: resolved (set by @alainfrisch on 2017-07-18T12:13:13Z)
Resolution: won't fix
Priority: normal
Severity: tweak
Target version: 4.06.0 +dev/beta1/beta2/rc1
Category: typing
Monitored by: @gasche @diml @hcarty
Bug description
When deprecating a recursive type, the definition itself triggers the warning. While this could server to remind the library writer to remove the definition later, I think it is more of a nuisance since the deprecation period may be long, and it is inconsistent with non-recursive type definitions and value definitions.
Steps to reproduce
type t = Z | S of t [@@ocaml.deprecated "Only for bug report."];;
Additional information
Tested with ocaml 4.02.3 and ocaml master checkout 2015-10-03.
The text was updated successfully, but these errors were encountered: