Better control over immutability

[jclark]

The goals are:

• to be able create immutable values without having to do a (deep) copy
• to be able to have variables (particularly at module level) whose values are computed at runtime, but are guaranteed immutable and so can be accessed safely from multiple threads

Note that we can already do the above for compile-time constants. The goal here is to extend this to values that are not known at runtime.

It is not a goal to guarantee at compile-time that immutable values are not written to. Some instances of this are caught at compile-time, but in general this is enforced at runtime. This is consistent with the overall design of the type system which guarantees that reads succeed and are type-safe, but does not make the same guarantee for writes. It is also consistent with what we do with const.

This could work as follows.

• Allow the following things to be explicitly declared as immutable:
  • variables
  • parameters
  • return values
• When something is declared as immutable, its type is constrained to be declared as a subtype of anydata|error
• Allow type-cast-expr to cast to immutable e.g. <immutable>

We could also use readonly instead of immutable.

Note that this does not allow types to be declared immutable, nor fields of records/objects.

Semantics are as follows:

• at compile time each expression has not only a type but mutability
• the mutability of an expression is either “immutable”, meaning “known to be immutable”, or unspecified meaning “not known whether it it is immutable or not”
• if the compile time mutability of an expression is “immutable”, it is guaranteed that at runtime the value of that expression will be immutable
• contextually expected type would generalize into something that also has contextually expected mutability (so for example, in return E the contextually expected mutability of E would come from the declared mutability of the return type of the function
• the type cast works with mutability exists as it works with type: it both sets the contextually expected mutability downwards at compile time, and verifies the mutability of the value upwards at runtime
• since type cast works with immutability, dynamic type test should also i.e. E is immutable

To explain this, it would help to have a word that means type (in the sense of shape) together with immutability. This could be called “type”, where type has two aspects, which are shape and immutability. However that does not fit with how we are already using the keyword “type” to describe just the shape aspect of type.

This is the second part of #186. It also relates to #145.

[jclark]

Give we are replacing freeze with readOnlyClone (see #186), the right keyword will be readonly rather than immutable.

[jclark]

Do we also need to say for a parameter that the immutability of the result comes from the immutability of an a parameter?

[jclark]

We would want the values of annotations to be constructed as immutable.

[jclark]

There is now a public proposal which covers this issue and #338. It is substantially different from what is described in the first comment on this issue.

[jclark]

I have created issues for parts of this, so we can stage the change:

• Add bare readonly type for inherently immutable basic types #462
• Remove error from anydata #463
• Allow record fields to be readonly #464
• Syntax for readonly and T #476
• Readonly type that allows immutable structural values #465

[jclark]

I separated the part of this relating to objects into #469.