Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

module abbreviations remove 'private' type restrictions #4816

Closed
vicuna opened this issue Jun 7, 2009 · 4 comments
Closed

module abbreviations remove 'private' type restrictions #4816

vicuna opened this issue Jun 7, 2009 · 4 comments
Assignees
Labels

Comments

@vicuna
Copy link

vicuna commented Jun 7, 2009

Original bug ID: 4816
Reporter: @jberdine
Assigned to: @garrigue
Status: closed (set by @xavierleroy on 2011-05-29T10:14:10Z)
Resolution: fixed
Priority: normal
Severity: minor
Version: 3.11.0
Fixed in version: 3.11.1+dev
Category: ~DO NOT USE (was: OCaml general)
Related to: #4933
Monitored by: furuse @jberdine letaris

Bug description

Consider the following code:

module M : sig
  type t = private T of int
  val mk : int -> t
end = struct
  type t = T of int
  let mk x = T(x)
end

module M' = M

let x = M'.mk 42

let y = M'.T(42)

With 3.10.2, the let binding for y fails to type-check:

        Objective Caml version 3.10.2
[snip]
# let y = M'.T(42);;
Characters 8-16:
  let y = M'.T(42);;
          ^^^^^^^^
Cannot create values of the private type M'.t

With 3.11.1+rc1, however, it type-checks:

        Objective Caml version 3.11.1+rc1
[snip]
# let y = M'.T(42);;
val y : M'.t = M'.T 42
#

David Allsopp reports the same behavior on 3.11.0.

@vicuna
Copy link
Author

vicuna commented Jun 8, 2009

Comment author: @garrigue

Fixed in CVS for 3.11.1.
A previous fix for private abbreviations had broken the behaviour for private types...

@vicuna
Copy link
Author

vicuna commented Jun 12, 2009

Comment author: @jberdine

I am still seeing different behavior with 3.11.1 regarding the typing of
private types. Consider the following code:

module M : sig
  type t = private T of int
  val mk : int -> t
end = struct
  type t = T of int
  let mk x = T(x)
end

module M1 : sig
  type t = M.t
  val mk : int -> t
end = struct
  type t = M.t
  let mk = M.mk
end

module M2 : sig
  type t = M.t
  val mk : int -> t
end = struct
  include M
end

module M3 : sig
  type t = M.t
  val mk : int -> t
end = M

With 3.10.2 this type-checks, but with 3.11.1, M1 type-checks but M2 and M3
fail:

Error: Signature mismatch:
Modules do not match:
sig type t = M.t = private T of int val mk : int -> t end
is not included in
sig type t = M.t val mk : int -> t end
Type declarations do not match:
type t = M.t = private T of int
is not included in
type t = M.t

Note that M1, M2, and M3 have identical meanings.

@vicuna
Copy link
Author

vicuna commented Jun 13, 2009

Comment author: @garrigue

Actually the second bug your report has a different cause.
Namely the case when the implementation type was a private concrete type,
and the interface type a public abbreviation referring to this type,
was incorrectly refused. The problem was in file includecore.ml.

This is fixed in CVS, branch 3.11, but too late for 3.11.1.

@vicuna
Copy link
Author

vicuna commented Jun 14, 2009

Comment author: @garrigue

Question to the original reporter:

It seems that ocaml-3.11.1 shipped with a partial fix, sound (i.e. private types are really private), but not complete (some correct re-exportations are refused by the compiler). So some correct software that compiled with 3.11.0 will not compile with 3.11.1. How bad is it for you? Do you know of any published software where such a problem occurs?
Since 3.11.0 was no sound, there may be also programs that took advantage of the unsoundness, but then refusing them is certainly correct.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants