Skip to content
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

[Suggestion]: Add --strictReadonlyChecks option to catch runtime errors modifying frozen objects at compile time #11481

Closed
paulkoerbitz opened this issue Oct 10, 2016 · 2 comments
Labels
Revisit An issue worth coming back to Suggestion An idea for TypeScript Too Complex An issue which adding support for may be too complex for the value it adds

Comments

@paulkoerbitz
Copy link
Contributor

The Problem
It is currently not possible to consistently catch modifications of frozen objects, which lead to runtime errors in strict mode. See #11180 and #11480 for examples.

Proposed Solution
Add a strictReadonlyChecks compiler option, which does not allow to assign readonly fields to non-readonly (regular) fields. Also do not allow deleting items from readonly dictionaries (#11480), unless this can already be solved by regular compiler behavior.

@mhegazy mhegazy added Suggestion An idea for TypeScript In Discussion Not yet reached consensus labels Oct 10, 2016
@RyanCavanaugh RyanCavanaugh added Too Complex An issue which adding support for may be too complex for the value it adds Revisit An issue worth coming back to and removed In Discussion Not yet reached consensus labels Oct 31, 2016
@RyanCavanaugh
Copy link
Member

Having this in any usable state would require a full set of variance and mutability annotations along with corresponding type operators -- a very large change. We're thinking about a future with some kind of variance / mutability annotations but won't be doing this as a one-off feature.

@DavidANeil
Copy link

I think there are 2 distinct things that I see in the issues referencing this one.

  1. A need for a readonly member to not be assignable to a readwrite member.
  2. A need for a readwrite member to not be assigned to a more inclusive type unless it is also marked as readonly.
    Would it be reasonable to address these issues seperately?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Revisit An issue worth coming back to Suggestion An idea for TypeScript Too Complex An issue which adding support for may be too complex for the value it adds
Projects
None yet
Development

No branches or pull requests

4 participants