add `enforceReadonlyAssignability` flag for smoother transition to true readonly modifiers

[zpdDG4gta8XKpMCd]

this can be seen in the nightly build as of Dec 17 (as well as at playground)

interface ReadOnlyData {
    readonly value: number;
}

interface WritableData {
    value: number;
}

function erase(data: WritableData): void {
    data.value = 0;
}

const readOnly: ReadOnlyData = { value: 1 };

erase(readOnly); // expected a type error, actual: no problem

this can't be serious, can it?
why is it called readonly?

please note there are no type assertions or any other attempts to trick the type system, it just simply doesn't work

50+ errors left uncaught

UPDATE

---

constructive discussion starts here: #13002 (comment)

[RyanCavanaugh]

This was described at #6532 (comment)

[dead-claudia]

@Aleksey-Bykov readonly basically means you may not modify it. It guarantees no actual immutability of the binding (heck, even Scala doesn't provide facilities that deep - val name = value and def name = value carry the same signature, and toString is a property). Consider it a case of "we're all consenting adults here", not "you shall not modify this value ever" (the latter is what Object.freeze is for).

[zpdDG4gta8XKpMCd]

@iashmeadows next time you are buying a car and you read "a sport BMW coupe", you say sweet, just what I wanted, you write a check, get your car and drive it home, next day you are all excited to show it to your friends, you stop at a store to get a 6 pack on the way there, you open the trunk and put your beer in it, when you close it you BMW turns into Honda Odyssey... you are like what? you are all pissed and stuff, you take the beer out and it turns into BMW again, you are like what!!! you call the dealer who sold it to you, they drop on you first, it's normal, then they pick up and say you know it's accoring to issue #6532 where some housewife complained that the trunk of BMW isn't big enough for shopping at Costco and taking kids to the beach, and that's exactly why we made a hard decision to turn iT into Honda Odyssey every time anything is put in its trunk, you are like wtf!!! So you go there and you are like: nothing was said about this shit anywhere! And what you hear back is: well we never said we sell true BMW''s why are you surprised? And people around who saw it are like: hey let's be adults here. F**k what?

[DanielRosenwasser]

Regardless of whether or not I agree on that perspective of readonly, I have to admit I enjoyed the analogy. 😄

[dead-claudia]

@Aleksey-Bykov In case you missed it, the "we're all consenting adults here" was a reference to a common saying in the Python ecosystem, regarding member privacy, types, etc. 😉

(Basically, conventions are usually sufficient to imply "you're on your own" for diving into internals, and there's only so much you can do to prevent them from doing it, especially without the use of closures.)

[aluanhaddad]

@isiahmeadows

In case you missed it, the "we're all consenting >adults here" was a reference to a common >saying in the Python ecosystem, regarding >member privacy, types, etc. 😉

Python gets a lot of things wrong. I never understood the appeal and popularity of that language. Irregardless that doesn't make it a good basis for anything.

It guarantees no actual immutability of the >binding (heck, even Scala doesn't provide >facilities that deep - val name = value and def >name = value carry the same signature, and >toString is a property).

I don't see the relevance, val and def both mean the reference, to a property method or variable, may not be reassigned. They differ in eagerness vs laziness and some other characteristics, type inference characteristics for example, but they don't have different mutability. With respect to deep immutability, which is not what is asked for here, Scala does allow it, you just have to use the right modifier, val or def, all the way down and not var. Scala does enforce this at the type system level.

Regardless, Scala has a nominal type system with support for optional explicit structural subtyping. Furthermore it doesn't permit these types of readonly violations. I don't think it is the right analogy.

I'm not saying TypeScript made a bad decision here, but personally I think it would have been great if readonly had resulted in code emit using defineProperty({ writable: false, ... }), at least it would have made classes useful. But that's a whole other argument.

[masaeedu]

Type driven emit would be nice in many scenarios, but even if we never get that, a type error here would be useful. Do readonly properties only get checked for reassignment within class members right now?

[danielearwicker]

Re: comments above, the issue here is not to do with emit, or the fact that readonly doesn't mean const. It's just the looseness of type checking between the interfaces with mismatched properties. If a property could be explicitly marked mutable, it would not be satisfied by a readonly property and the conversion disallowed.

[zpdDG4gta8XKpMCd]

here is a dichotomy: a property is either readonly or writable, there is no other outcome

when we say { x: number } we mean writable x
when we say { readonly x: number } we mean x is only for reading

what else do we need? what is the third state implied by mutablem

[danielearwicker]

That would be the ideal if the readonly modifier had existed forever. The problem is backward compatibility. To quote @ahejlsberg in the comment linked to above:

Specifically, we can't interpret the absence of a readonly modifier to mean read-write, we can only say that we don't know. So, if an interface differs from another interface only in the readonly modifiers on its properties, we have to say that the two interfaces are compatible. Anything else would be a massive breaking change.

So now we have a trichotomy:

{ readonly x: number } - x is definitely not writable
{ mutable x: number } - x is definitely writable
{ x: number } - x may or may not be writable - coder has not specified

If mutable was added to the language then your:

interface WritableData {
    mutable value: number;
}

would no longer be compatible with ReadableData. It would allow us to specify definite mutability wherever we needed that safety.

I think of this as similar to the bivariance compromise in TS today. Any fix to it in the future will allow us to improve the situation where we ask for it, but the default will have to continue to be bivariance, to avoid breaking so much existing user code.

(OTOH as TS 2.0 was a major version bump, maybe a massive breaking change would be acceptable to some, but TS is more cautious than that, which is a good thing IMO).

[aluanhaddad]

@Aleksey-Bykov Indeed a mutable modifier is effectively meaningless. Everything is mutable unless otherwise indicated.

@danielearwicker specifically for that reason there should not be new syntax because the old syntax will have to mean what the new syntax means implicitly and indefinitely. All this will do is create cognitive load

[abenhamdine]

Specifically, we can't interpret the absence of a readonly modifier to mean read-write, we can only say that we don't know. So, if an interface differs from another interface only in the readonly modifiers on its properties, we have to say that the two interfaces are compatible. Anything else would be a massive breaking change.

It could be behind a flag : usually it's a convenient way to handle these kind of breaking changes.