Joe Pea

So why not choose the design that would be more practical for most people (source-positional), and let those people who want particular security guarantees use WeakMap to do whatever they...

The fact we can mix `function`s with `class`es was a _feature of the language_ before `#private` fields was. You always like to play on words only to be in an...

I've been writing UI code, looking at other people's UI code, and working in Node.js applications for plenty of years now, and from this experience I believe source-positional private fields...

@rdking @ljharb I know I can do what I want with WeakMaps. I just feel that people with more obscure cases can also do the more obscure things with WeakMaps...

Oh, I forgot to say: I don't see why elevating private fields to module scope means we can't ship them. It merely swaps the use cases that the feature is...

> Think of the semantics. A "private" member is one that can only be accessed by its owner. If you "elevate" that from `class` scope to module scope, you've essentially...

Sidenote, the reason I said "moved to top-level module scope" is because that's the only way in which transpiler (like Babel or Buble) would be able to polyfill it. In...

> The use of private names from a module-level scope still doesn't satisfy the typical use case of "private" members. Hence elevation to module scope to make it "source positional"...

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

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