add a constraint for immutable types

say, i have a generic function that by design requires that its parameters may only take immutable arguments, i wish i could get such guarantee from TS by declaring my function as follows:

function doThings<readonly T>(value: T): Result<T> {
   // ...
}

as far as how to make an interface immutable:

readonly interface Point {
   readonly x: number;
   readonly y: number;
}

so the problem being solve here is to make sure that the caller won't mutate the argument after it is passed to the function

simple use case: a hash-based data container, which calculates a hash of a given value, and will store it at that hash, and it all will work until the value is mutated outside and tha stored hash is no longer valid, so the container doesn't really work anymore

another use case: a cache or object pool or any other situation when there are many parties involved in taking hold of the same object, which must be guaranteed from being mutated by one party to prevent spooky action at a distance for all other parties

Readonly<T> should give you a shallow readonly support. For the deep readonly, #10725 already tracks adding that.

i was talking about special generic constraints that would guarantee that a type argument is immutable

what did you mean by Readonly?

interface Writable {
    value: string;
}
function willOnlyTakeReadonly<T>(data: Readonly<T>): void {
}
declare const writable: Writable ;
willOnlyTakeReadonly(writable); // <-- no problem

i am afraing it doesn't work at least in the latest version of TS, because anything can be used in place of Readonly<T> parameter including interfaces with all writable properties

Aleksey-Bykov

Aleksey-Bykov you can't mutate the input though

type Writable = {
  value: string
}

function willOnlyTakeReadonly(data: Readonly<Writable>): void {
  data.value = 'a' // error Cannot assign to 'value' because it is a constant or a read-only property
}

declare const writable: Writable

willOnlyTakeReadonly(writable)

not sure I understand then, what did you have in mind constraining the Input?

i added 2 use cases that shed some light on when/why it is useful to constrain the input

any reason why it was closed?

I support the goals of this proposal. Some design issues:

For the interface modifier that asserts that the object is immutable, overloading the readonly keyword is very confusing (it looks like it already confused mhegazy). Ideally we should use immutable, though I don't know if there are concerns about adding new reserved words. (I'll use immutable in the rest of my comment.)
What prevents an interface containing the same members without the readonly modifier from being assigned structurally to the Point interface as declared above? Is the immutable modifier of a type one more thing that is checked for assignability?
Users may want mutable, read-only, and immutable versions of the same interface. The current proposal for read-only (Support readonly type operator to allow correct definition of Object.freeze #10725 / Strict variance and read-only versions of types #18770) is that the user defines a mutable interface Point and writes readonly Point for a deep read-only version (perhaps what "deep read-only" means has to be customized in some cases). Similarly, I'd like to write immutable Point for the deep-immutable interface. In essence, the immutable operator should declare fields that form part of the abstract state of the object to be immutable themselves; these are the same fields that become readonly along with the interface. The immutable interface has the same methods as the readonly interface. Given such an operator, the original example could be written as:

function doThings<T>(value: immutable T): Result<T> {
   // ...
}

but additionally having an immutable type parameter constraint may be clearer for users and/or make implementation easier depending on how type argument inference works (yikes).

How do users produce immutable objects? One way is always a type assertion, or a deepFreeze method that uses reflection to find out what fields it should recursively deepFreeze and then asserts the result to be immutable. We could additionally consider ways of constructing a single new immutable object from existing immutable parts, e.g.:

immutable {a: 1, b: 2}
immutable [3, 4, 5]
immutable new MyPair(point1, point2)

To use the same constructor to construct both mutable and immutable objects, we need to make it polymorphic in whether the new object is mutable. I.e., we think of the presence or absence of the immutable modifier on the call as a generic parameter of the constructor, and throughout the constructor's signature and body, the owned type modifier refers to this parameter. Then the compiler checks every assignment to a field to ensure that if the new object is immutable, then the reference being assigned is immutable. (Is anyone aware of precedent for this in other programming languages? I could research it myself, but I've spent enough time on this already.)

Navigation Menu

Repository navigation

add a constraint for immutable types #14909

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

add a constraint for immutable types #14909

Description

Activity

mhegazy commented on Mar 29, 2017

zpdDG4gta8XKpMCd commented on Mar 29, 2017

gcanti commented on Mar 29, 2017

mhegazy commented on Mar 29, 2017

zpdDG4gta8XKpMCd commented on Mar 29, 2017

zpdDG4gta8XKpMCd commented on Apr 21, 2017

mattmccutchen commented on Sep 26, 2017

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions