-
Andrei Paskevich authored
this should not be problematic as long as these fields do not occur in the invariants (actual or refined). In other words, a value of a private type exists no matter what is stored in the field. Also, admit non-private mutable types without actual mutable fields. It is actually impossible to create a write effect for such types, and the only consequence of being mutable is that they are assigned a region, and so every value of such type can be tracked individually. One use case for this is a non-private record with an invariant, which either has fields with mutable types or has type parameters that we wish to instantiate with mutable types. If we modify these mutable components, this may break the record's invariant. Now, if the record itself is immutable (and thus has no associated region), then we must reestablish the invariant immediately, otherwise we lose track of the value. Even if this extra flexibility does not prove useful in the end, it seems to be harmless. Also, admit type definitions of the form type t 'a = (private|abstract)? mutable? {} invariant* which define private empty records (even if not declared private). Also, "type t 'a" is now equivalent to "type t 'a = private {}".
f522e56e