Open zpdDG4gta8XKpMCd opened 7 years ago
Readonly<T>
should give you a shallow readonly support. For the deep readonly, https://github.com/Microsoft/TypeScript/issues/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 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 (#10725 / #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.)
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:
as far as how to make an interface immutable:
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