Immutable const?

# jeremy nagel (2 years ago)

was just chatting to colleagues about the utility of const. The fact that it doesn't actually lead to immutable objects or arrays seems to make it a bit toothless and misleading. Are there any proposals to have an immutable version of const? I know you could use ImmutableJS but it would be nice to have this part of the language.

Perhaps the keyword could be final.

# Yad Smood (2 years ago)

I think final is a bit different from immutable. When you use final (Java) it means you can only set it once. But when you use immutable it means every time when you set it, it creates a new object. Since let (like Haskell) is already reserved by JS. How about def or directly use immutable?

# Michał Wadas (2 years ago)

Actually it isn't useless - limiting variable reassignment significantly increase code readability. Immutability is different use case and it's actually impossible to get immutability when we consider exotic objects and getters/setters.

# Yad Smood (2 years ago)

The string in V8 is internally immutable, so it may be not that hard to add this feature?

# Reinis Ivanovs (2 years ago)

This idea sounds like having a version of the const keyword that also freezes objects, but that's a far cray from what Immutable.js does, which is about persistent data and collection methods. Freezing also doesn't work on things that use mutator methods like Map or Set, so it'd be confusing.

# Isiah Meadows (2 years ago)

JS doesn't have immutable types, which is why Object.freeze simply says "don't change this object's own properties". Frozen objects make for nice enumerated types, but JS has no notion of immutability. Additionally, you have to take into account the internal slots, which freezing objects has no effect on (it only has an effect with the internal object.[[Get]] and object.[[Set]] methods).

Isiah Meadows me at

# jeremy nagel (2 years ago)

Ok I may have been misusing terminology. What I mean is more of a deeply frozen object along the lines of what happens with

The argument for it would be that we've had quite a few bugs where other modules have modified an instance of an object that gets passed around. We now often deep clone parameters at the start of methods to avoid this happening. Would be nicer if deep clone was not required as that has a performance hit.

Edge cases where custom getters or setters could be avoided by throwing an error if someone attempted to do frozen/final/whateverTheTermWouldBe someComplexObjWithGetters = ...

Jeremy Nagel 0414 885 787

# jeremy nagel (2 years ago)

Just realised this is probably covered by the frozen realms proposal: FUDCo/proposal-frozen-realms

Jeremy Nagel

# Alexander Jones (2 years ago)

IMO we should unblock anything that stands in the way of ergonomics when using new product type types, other than Object. If I can write code using Immutable.Map as succinctly as I can Object then we're half way there. See for discussion on generalized map and list literals.

Formalizing things like object spread and destructuring to work on other types would be important, too.

Then, who knows, in ES2019 we might adopt Immutable or something like it into the core library...