-
Notifications
You must be signed in to change notification settings - Fork 12.6k
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
immutable types #11535
Comments
Note that a proposal and implementation would be nearly identical to subset types at #11233, just with a different operator. |
@andy-ms points out that if we implement this as a type operator, the syntax should probably be |
@sandersn Actually, there would be a significant difference from subset types in that readonly (or const) would be a deep operation, whereas subset is shallow. |
proposed solution is suitable for both deep and shallow |
alternatively it would be great to get |
In addition I would like to purpose a situation:
interface RegularInterface {
regularMember: string;
}
interface AllReadOnlyInterface {
readonly memberA: number;
readonly memberB: number;
readonly regular: ReagularInterface;
} problem:
solution:
interface RegularInterface {
regularMember: string;
}
readonly interface AllReadOnlyInterface {
memberA: number; // memberA is readonly
memberB: number; // memberB is readonly
regular: ReagularInterface; // regular is readonly
} |
@Aleksey-Bykov I really want to see this in the language. It helps to solve a myriad of recent issues and allows for some very flexible programming models. It has lots of practical applications. For example wanting to retrieve and expose immutable data from an Http client but allowing a mutable It also fills a nice conceptual space in the language and helps to build idiomatic, JavaScript-embracing correspondence between compile time and runtime strictness. We could finally get fairly accurate, highly useful type definitions for functions such as deep-freeze-strict. This would be a big win. @NoHomey |
In case anyone finds this issue in a search, it's about read-only interfaces, not immutable ones, despite the title. The correct issue for immutable interfaces is #14909. |
situation:
i need an interface 100% similar to a given one but with all properties readonly:
problem:
in order to get
MyConfig
immutable i have to effectively re-declare it with all properties which is a lot of work and maintenance:solution:
allow special declaration that produces a readonly version of an interface based on the original one :
The text was updated successfully, but these errors were encountered: