Joe Pea

> 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 > 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,...

> Notably, tho, the conflict you (@rdking) describe (in https://github.com/tc39/proposal-class-fields/issues/248#issuecomment-502836378) only applies for those that care about Set semantics - which would only be those participating in an inheritance hierarchy...

> I’m one of the ones that spent over a year fighting for Set, Sorry, missed that part. You shouldn't have stopped fighting for it.

I don't think so, because I can easily run `this.foo = whatever` inside a constructor. It's not super critical to rush it just because we can save keystrokes from deleting...

For private fields, it doesn't matter, there's no inheritance. So, we don't care about those in this case. For static fields, I'd say it should respect inheritance too (use [[Set]])....

The type of composition @ljharb mentions is great. But so is inheritance. They both have their place. Anywho, I do not think that is what the OP is asking about....

You all are lucky you can work on such things, _on a Monday_. I have only short evenings and mostly weekends if I choose to voice any opinions on this...

TLDR: https://github.com/tc39/proposal-type-annotations seems better to me. But I also don't like them being ignorable. Can we fork that proposal and make them non-ignorable. Actual type checking would be awesome (but...

Ah, thanks! I'll give that a go soon..