Suggestion: read-only modifier

Some properties in JavaScript are actually read-only, i.e. writes to them either fail silently or cause an exception. These should be modelable in TypeScript.

Previous attempts to design this have run into problems. A brief exploration:

interface Point {
    x: number;
    y: number;
}
interface ImmutablePoint {
    readonly x: number;
    readonly y: number;
}
var pt: ImmutablePoint = { x: 4, y: 5 }; // OK, can convert mutable to non-mutable
pt.x = 5; // Error, 'pt.x' is not a valid target of assignment

var pt2: Point = pt; // Error, cannot convert readonly 'x' to mutable 'x'

// Possibly bad behavior
var pt3: Point = { x: 1, y: 1 };
var pt4: ImmutablePoint = pt3; // OK
pt3.x = 5; // pt4.x is also changed?

// Really bad behavior
/** This function was written in TypeScript 1.0 **/
function magnitudeSquared(v: { x: number; y: number }) {
   return v.x * v.x + v.y * v.y;
}
// Now try to use it with ImmutablePoint
console.log(magnitudeSquared(pt)); // Error, cannot use readonly object in non-readonly call

Possible solutions?

Allow bivariance of mutability: this is very unsound
Something else clever? C++ did not do well with const contamination

I think this is probably the most important feature in terms of making Typescript a safer language. E.g. You are guaranteed that the object will not be mutated along the way and that simplifies reasoning a lot.

however, I don't see the problem with magnitudeSquared, it does not change 'v', so, it should work fine with both read-only and mutable objects.

👍

I don't see the problem with magnitudeSquared, it does not change 'v',

The problem is, you don't know this without reading the function implementation, and you might not have access to the implementation. Let's say someone gives you their library with a 1.0 TypeScript definition file:

// Docs say: calculates the squared magnitude of a vector
declare function magnitudeSquared(v: { x: number; y: number }): number;
// Docs say: rescales a vector to have length 1 and returns
// the scale factor used to normalize the vector
declare function normalize(v: { x: number; y: number }): number;

One of these functions modifies the object, one of them doesn't. You can't tell by looking at their signatures -- they're identical.

Now we have two obvious options

Assume all functions arguments are actually treated as read-only?

That fails to catch this problem

var p: ImmutablePoint = { x: 1, y: 3 };
var pN = normalize(p); // Failure to catch immutability violation

Worse, now you have to opt in to non-readonliness. When you upgrade your definition file to have the read/write information, now you're going to have to write mutable basically everywhere:

// I have to write the word 'mutable' this many times?
declare function normalize(v: { mutable x: number; mutable y: number }): number;
declare function invert(v: { mutable x: number; mutable y: number, mutable z: number }):void;
declare function changeRotation(v: { mutable theta: number; mutable phi: number }): void;

Assume all function arguments are actually mutable?

Now I can't use magnitudeSquared without a cast:

var p: ImmutablePoint = { x: 1, y: 3 };
var len = magnitudeSquared(p); // Error, this function might modify p!

And you get to write readonly everywhere:

// I have to write the word 'readonly' this many times?
declare function magnitudeSquared(v: { readonly x: number; readonly y: number }): number;
declare function length(v: { readonly x: number; readonly y: number, readonly z: number }): number;
declare function dotproduct(v: { readonly theta: number; readonly phi: number }): number;

Can this be re-opened as a request? Given the increased use of functional programming with JavaScript and immutable data structures (see React and Flux). I think this would be great as an opt-in feature, maybe with a top-level decorator enabling it to avoid the issues of default behavior (i.e. ignore the check by default).

I'm not sure what you're asking? The issue is currently open.

Sorry, misread the status.

+1 for readonly keyword support.

Ryan Cavanaugh (@RyanCavanaugh)

+1 for something along these lines. The problems described by Ryan Cavanaugh (@RyanCavanaugh) are quite real but the suggestion by Joe Wood (@joewood) to have some sort of decorator seems to be a smart one. I guess it might be along the lines of 'use strict' at the start of functions but probably more explicit, like
mutable class vs immutable class
and
mutable module vs immutable module
to specify the defaults within a block of code at the module or class level. For back-compat reasons, mutability would have to be assumed, right?

Perhaps along the same lines, where ? is used on a parameter to indicate it's optional, could other annotations be added, along with one indicating either (like how any throws away types)?

"The perfect is the enemy of the good." As TypeScript stands today, the compiler won't even tell me when I set a property with no setter -- with the full implementation available. This has been raised as an issue multiple times, and those other issues all point back to this one, so it seems pretty important that progress be made in this area. To me, ~~having the readonly decorator and~~ catching the assignment-with-no-setter error would be a huge step in the right direction, even if it doesn't solve the third-party library problem.

Edit: Removed reference to readonly decorator. Readonly is a tar pit, and my point is around get/set, not interfaces.

+1 for a readonly modifier or similar. The scenario I am frequently running into is wanting to define an interface with properties that only requires a getter, which I would then expect the compiler to enforce by generating an error if the code tries to set a readonly property. Implementations would be free to provide a setter if they choose to do so, but it should only be usable in code if the object is being referenced as the implementing class or a derivative of it.

My personal preference would be the way c# does it, allowing you to specify get and/or set in the interface, but the readonly case is by far the most useful (other than the full get/set case).

Ryan Cavanaugh (@RyanCavanaugh)

Thinking out loud here:

While readonly fields are important, perhaps an easier thing to implement, which doesn't have some of the problems Ryan Cavanaugh (@RyanCavanaugh) outlined is immutable classes/interfaces.

Suppose you have:

immutable interface ImmutablePoint {
    x: number;
    y: number;
}

Given the properties of an imutable object, we can change how assignment behaves, to instead clone and freeze in JS.

So that:

var pt3: Point = { x: 1, y: 1 };
var pt4: ImmutablePoint = pt3; // OK -- pt3 is copied
pt3.x = 5; // pt4.x -- does not change

The pt4 assignment would basically look like:

...
// compiled JavaScript
var pt4 = pt3.clone(); // your favorite clone() scheme
pt4.freeze();
...

The compiler can then optimize the clone & freeze into only a freeze if:
1- we are using a literal assignment
2- possibly, if the variable/value we are copying is dead after this line (when dealing with global scope ,etc.)

Some problems remain with this:

Unclear what to do about deep properties; I'm tempted to say "nothing" here... the immutability guarantee might be seen as a guarantee to not change references to other objects (values of pointers), rather than values within these objects.
For the magnitudeSquared problem, we'd need to declare it as magnitudeSquared(v: immutable v { x: number, y: number }).

I was actually thinking of something more like the const modifier in C++. This would be applied to the object instance, providing an immutable view of an existing object. So something more like:

interface Foo {
    x : number;
    getConstBar() const : const Bar;
    getBar() : Bar;
}

function doNotMutate( obj : const Foo ) {
   obj.x = 3; // !! compiler error
   var bar = obj.getBar(); // !! compiler error, cannot call a non-const function 
   var constBar = obj.getConstBar(); // OK, can invoke a const function now have a const Bar
}

function mutate( obj: Foo ) {
    obj.x = 3; // works
    var bar = obj.getBar();  // works too
}

This way it's an opt-in on the interface, and can be passed down to child objects through accessor functions (or getters) that are declared const. Declaring a function const essentially applies the modifier to this (again, in the same way as C++ works).

So, in practical terms for libraries like react.js, the setState function would be mutable but the accessor functions to state and props would be immutable.

I prefer Eyas' suggestion. It's clean and simple. JavaScript has so many ways to modify state: adding/removing/deleting properties, side-effecting getters, proxies, etc. that introducing a concept like const will necessarily be horribly complicated.

There's also the issue of claiming that a method or argument in a JS library is const when it turns out not to be; there's no way to check it and not even runtime errors will be generated unless the compiler wraps arguments in a read-only proxy.

And readonly x: number is not good enough?

Or u r looking for public get private set?

Joel Day (@joelday)

It is debatable and as I said I didn't find what is considered to be a good practice.
The main concern is that readonly becomes 'read-write' in the output JS and it can be changed by some bad code.
Joel Day (@joelday) Suggests to use get-only properties in the class though.
Mohamed Hegazy (@mhegazy) Yes, but be more specific , constructor only set.

Terse get syntax like C# was discussed in #10911.

Since properties (at the moment) aren't ES spec, it could be argued though that the readonly modified in a class could make a non-writable value descriptor. If someone wanted to truly shadow the value, a getter only would be the other way. So this:

class A {
  readonly a = 'foo';
  get b() {
    return 'bar';
  }
}

Would de-sugar to:

var A = (function () {
    function A() {
    }
    Object.defineProperty(A.prototype, "a", {
        value: 'foo',
        writable: false,
        enumerable: true,
        configurable: true
    });
    Object.defineProperty(A.prototype, "b", {
        get: function () {
            return 'bar';
        },
        enumerable: true,
        configurable: true
    });
    return A;
}());

Why is readonly diffrent from private? Privacy is not maintained in the generated js either.

Mohamed Hegazy (@mhegazy)

Mohamed Hegazy (@mhegazy) You are correct. I mistakenly thought that private members are implemented in some different way.
Then it makes sense for same way readonly implementation.

I guess it is offtopic now. It needs some other syntax for truly readonly properties to be implemented by defineProperty and privates via symbol or some other nice hack.
Thanks.

The usage of readonly is not completely clear for me. I wrote a question on Stackoverflow.

This following code compiles, but is it semantically correct?

interface Counter {
  readonly name: string
  readonly value: number
  inc(): number
}

function counterFactory(name: string): Counter {
  let value = 0
  return {
    get name() {
      return name
    },
    get value() {
      return value
    },
    inc() {
      return ++value
    }
  }
}

The member value is declared as readonly but its value is changing.

I would like to know if this use of readonly on the member value is a good way to proceed. The syntax is OK. But is this example semantically correct in TypeScript? Is that what the modifier readonly is for?

Thomas Mur (@paleo)

Thomas Mur (@paleo) readonly is similar to const, it doesn't define deep immutability, just some way to make less mistakes.

const x = {a:1};
x = {a:2}; // Error , cannot change x
x.a = 2; // Ok, const is not deep

let x: {readonly a:number;} = {a:1};
x = {a:2}; // x is mutable do whatever you want
x.a = 2; // Error, 'a' is readonly and doesn't allow reassignment.

For true immutability, you need to write code which makes types immutable.

Thomas Mur (@paleo)

Thomas Mur (@paleo) readonly doesn't guarantee that a value won't change in time, it just doesn't let you write to it. That's why the word is readonly, not constant.

it just doesn't let you write to it

that's not true either: #13002

Aleksey-Bykov

Aleksey-Bykov Previous issue title was a bit closer then...

Anders Hejlsberg (@ahejlsberg)

I quote Anders Hejlsberg (@ahejlsberg) from his PR:

A good way to think of it is:

readonly = cannot be modified by me

const = cannot be modified, period

In my question on StackOverflow, I wrote two use cases using readonly. The first case matches well to "cannot be modified by me". But the second case, that I have reported above, would rather be a "cannot be modified by you".

Is that what the modifier readonly is for? Is it valid from a semantic point of view?

Is that what the modifier readonly is for? Is it valid from a semantic point of view?

Like a lot of the TypeScript typing system, it is not enforceable at run-time, it is a type contract. const is a ECMAScript run-time concept which TypeScript can fully model the run-time behaviour. readonly correctly aligns to run-time behaviour when the property in question has a getter only or is a value property that is not writable. At other times, it is a design time only construct to improve type safety (just as string or number are design time only constructs).

Ryan Cavanaugh (@RyanCavanaugh)

readonly correctly aligns to run-time behaviour when the property in question has a getter only or is a value property that is not writable.

Thank you, it's clearer.

I realize that I already had the answer in 2016, from Ryan Cavanaugh (@RyanCavanaugh) . At that time the ES5 getter solution was not available to me because my code had to remain ES3 compatible, so I left angry and didn't take the time to understand the information. He said:

You can already have a getter-only wrapper around a private variable, which achieves the same semantics at the cost of slightly increased class size.

This is the final answer: yes, the readonly modifier can be used with an ES5 getter to achieve this semantics.

Navigation Menu

Suggestion: read-only modifier #12

Assume all functions arguments are actually treated as read-only?

Assume all function arguments are actually mutable?

112 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Suggestion: read-only modifier #12

Description

Activity

everson commented on Jul 21, 2014

basarat commented on Jul 30, 2014

RyanCavanaugh commented on Jul 30, 2014

Assume all functions arguments are actually treated as read-only?

Assume all function arguments are actually mutable?

joewood commented on Nov 4, 2014

RyanCavanaugh commented on Nov 4, 2014

joewood commented on Nov 4, 2014

Jxck commented on Nov 19, 2014

IanYates commented on Nov 19, 2014

RandScullard commented on Nov 19, 2014

danpaul88 commented on Nov 25, 2014

Eyas commented on Nov 27, 2014

joewood commented on Nov 29, 2014

metaweta commented on Dec 13, 2014

112 remaining items

mhegazy commented on May 20, 2017

mhegazy commented on May 20, 2017

NN--- commented on May 20, 2017

kitsonk commented on May 20, 2017

mhegazy commented on May 20, 2017

NN--- commented on May 20, 2017

paleo commented on Sep 25, 2017

NN--- commented on Sep 25, 2017

raveclassic commented on Sep 26, 2017

zpdDG4gta8XKpMCd commented on Sep 26, 2017

raveclassic commented on Sep 26, 2017

paleo commented on Sep 26, 2017

kitsonk commented on Sep 26, 2017

paleo commented on Sep 27, 2017

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions