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: 6603 Reporter:@alainfrisch Assigned to:@lpw25 Status: assigned (set by @alainfrisch on 2014-10-08T08:20:43Z) Resolution: open Priority: normal Severity: minor Category: documentation Monitored by:@gasche
Bug description
The behavior of extension constructor definitions/declarations when the target type is an abstract one is not documented in the manual. The behavior is:
In structures, it is allowed to rebind existing constructors to a type which is abstract in the current scope; it is not allowed to add new constructors, tough.
In signatures, it is possible to specify constructors added to an abstract type.
The following is thus accepted:
module type S = sig type t type t += A end;;
module F(X : S) : S = struct type t = X.t type t += A = X.A end;;
I assume that the rationale is to allow "sealing" an extensible type in a signature (together with a list of known constructors) , while allowing from the outside to expose subsets of its known constructors.
I suggest to describe the behavior in the manual, and give hints of situations where declaring extension constructors on abstract types is useful.
The text was updated successfully, but these errors were encountered:
Original bug ID: 6603
Reporter: @alainfrisch
Assigned to: @lpw25
Status: assigned (set by @alainfrisch on 2014-10-08T08:20:43Z)
Resolution: open
Priority: normal
Severity: minor
Category: documentation
Monitored by: @gasche
Bug description
The behavior of extension constructor definitions/declarations when the target type is an abstract one is not documented in the manual. The behavior is:
In structures, it is allowed to rebind existing constructors to a type which is abstract in the current scope; it is not allowed to add new constructors, tough.
In signatures, it is possible to specify constructors added to an abstract type.
The following is thus accepted:
I assume that the rationale is to allow "sealing" an extensible type in a signature (together with a list of known constructors) , while allowing from the outside to expose subsets of its known constructors.
I suggest to describe the behavior in the manual, and give hints of situations where declaring extension constructors on abstract types is useful.
The text was updated successfully, but these errors were encountered: