Use [[Set]] by default, add `define` keyword. (was: TypeScript class fields have [[Set]] semantics.)

[trusktr]

Class-fields in TypeScript have [[Set]] semantics. Foresee code breaking when JavaScript projects convert to TypeScript (or vice versa), and the pain caused from hard-to-find bugs, because of JavaScript class-fields using [[Define]] semantics.

I know this has been discussed in other threads, but I thought I'd open an official issue for it.

---

EDIT: Why not add a define keyword:

class Foo {
  foo = 'foo' // uses [[Set]] semantics
  define bar = 'bar' // uses [[Define]] semantics
}

Honestly, it would make most people (talking about end users who develop products, not language designers or implementors) happy.

[trusktr]

I was very pleasantly surprised by TypeScript when code didn't break after extending the types and default values of certain props in my subclass (which are getters/setters in the super class), using class fields.

I love that TypeScript chose [[Set]] so that I was able to take advantage of super class getters/setters while still allowing my subclass definition to be clean and simple.

[ljharb]

JavaScript code will not break; typescript code has always risked breakage by adopting features prior to stage 3.

Define semantics are shipping, and the committee (including typescript team members) settled this question in 2017 - I’d rather we had decided on Set, but this is the consensus we arrived at.

[nicolo-ribaudo]

This is how the TS team will address this change: microsoft/TypeScript#27644 (comment)

[trusktr]

JavaScript code will not break

Not sure why you'd say that. Changing properties from [[Define]] to [[Set]] semantics (f.e. converting JS to TS), or vice versa, can clearly break things.

For example, this is JS code:

class Child extends Parent {
  x = 0
}

The following TS code,

class Child extends Parent {
  x: number = 0
}

will be converted to use [[Set]], even if target is es2019. This is the output:

class Child extends Parent {
    constructor() {
        super(...arguments);
        this.x = 0;
    }
}

This is how the TS team will address this change: microsoft/TypeScript#27644 (comment)

Breaking people's code when they update to TypeScript 3.6 doesn't sound like a nice idea. I hope they leave [[Set]] as the default behavior, and only allow the new behavior as a compiler option.

[[Set]] encapsulates what JavaScript has already been for many years before class fields, and it is what people know. Why make such breaking changes to existing paradigms and mental models, replacing them with less convenient mechanisms?

[trusktr]

typescript code has always risked breakage by adopting features prior

And TypeScript also proved people love and widely enjoy the feature ([[Set]] semantics), yet TC39 didn't mind sacrificing that.

[ljharb]

Despite advocating for Set for years, I would be very surprised if even a percent of users ever cared about the difference.

[rdking]

How will you ever know? As is always the case, when bad decisions are made that don't completely break the language, they just end up in "the bad parts" lists, and people passively work around them. If the people who vocally frequent these discussion boards were to be considered a representative sample of the ES community (it's not, but for the sake of argument), then it would already be clear that more than 1% of us think that it makes little sense to use [[Define]] semantics on instance objects. It's not consistent with anything else in ES.

The fact that it's a new feature doesn't excuse or justify unnecessarily breaking known paradigms. No matter how much you try to brush away complaints by saying its already shipped, that's not going to improve anyone's opinion of the decisions or fix the common use cases that have been broken. Most of the disappointment comes from the apparent contradiction between TC39's desire to not break existing code while showing little to no caution toward breaking existing paradigms that are not directly related to the new feature.

All we want is to be able to declaratively define properties that will appear on each instance of the class. If Initialization is part of that definition then shouldn't it be just as immutable as the field being defined? By immutable, I mean that no one can dynamically alter the class definition to change the name of, remove, or otherwise alter the field declaration in the class definition. Even decorators don't do this. If a dynamic initializer is what is wanted, shouldn't that be done in the constructor? Even if avoiding the constructor is desired, the dynamic initialization should still proceed as if a human had written constructor code. That means [[Set]] semantics. The point is that instance properties shouldn't interfere with prototypal inheritance unless the developer wants it to on a case-by-case basis.

---

The rant above is a justification for [[Set]] semantics. If a similar justification for [[Define]] semantics exists, can someone please post it? NOTE: the FAQ contains no such justification, merely an explanation of the decision that was made. What I'm looking for is "WHY!?"

[ljharb]

One justification, as I understand it, was that many committee members felt it important that all the code in the class body be declarative - in other words, if they see foo = 1, and nothing in the constructor deleting or changing it, that should be sufficient for them to know with certainty that an instance of that class has foo initially set to 1. Set semantics means they'd also have to traverse the entire class hierarchy - which could be runtime values in extends, so not statically knowable.

[rdking]

Thanks for the quick response. Hasn't that been faulty reasoning from the beginning? Every language supporting calculated members violates that notion unless the member is either private or overridden.

[rdking]

It just hit me. This is a problem of conflicting goals. Correct me if I'm wrong, but both of these appear to be goals for this proposal:

• Any public, lexically scoped field declaration must override any existing inherited field of the same name from any superclass. (This is the only way to gain the certainty you spoke of.)
• Field initializations must be dynamic to allow for constructor-less classes with initialized fields.

The problem?
Almost no one would use defineProperty to create a field unless they were either modifying the attributes of the field, creating an accessor, or intentionally trying to hide an inherited field. In all other cases, simple assignment is the defacto standard.
So on the one hand, you've got people trying to avoid constructor(){} but wanting to initialize fields.
On the other hand, every element in a class statement is a "define" and automatic override.
Therefore, you end up with people wanting to initialize fields outside the constructor and ending up defining new ones instead.

That means the goal of avoiding the constructor is completely lost to those simply trying to initialize base-class fields. The advertised ability to omit constructors for doing simple field initializations is broken.

[ljharb]

Notably, tho, the conflict you describe only applies for those that care about Set semantics - which would only be those participating in an inheritance hierarchy that also uses setters.

[rdking]

You do realized you just described many framework, library and tool authors, right? Even though it's only going to be a small percentage of ES developers, what that small percentage does affects a large percentage of ES developers. You shouldn't be so quick to diminish secondary effects.

[hax]

I’d rather we had decided on Set, but this is the consensus we arrived at.

@ljharb There is no real consensus in community, several authors of big frameworks/libraries never accept [[Define]]. And there is also no real consensus in TC39, if read the meeting notes, you can find some guys in one meeting said he don't accept [[Define]] (or said if using [[Define]], it must use keyword), but the objectors just disappear for unknown reason in next meeting which "arrive the consensus". Is it a real consensus? I can never agree.

And assume if there is new member and delegates come into TC39 who never agree current design and refuse to allow it go to stage 4, what will happen?

[hax]

I would be very surprised if even a percent of users ever cared about the difference.

@ljharb This is the point. Most users don't want to care about it, but unfortunately it will affect their codes and life.

[ljharb]

@hax I’m one of the ones that spent over a year fighting for Set, and ended up agreeing to consensus on Define, because the feature is important enough that letting it never happen wasn’t acceptable.

Once it’s stage 3 and two browsers are shipping it, it’s web reality - so it would be pretty strange for someone to object to stage 4 at that point. It could certainly happen - it just wouldn’t change anything.