Kevin Gibbons

If you're interested in the history, see https://github.com/tc39/proposal-class-fields/issues/60, especially https://github.com/tc39/proposal-class-fields/issues/60#issuecomment-345540567.

In part just because of the history of the proposal: classes are the place where private fields were most obviously important (since you cannot easily substitute a closure for the...

In addition to @ljharb's comment, it would also be really annoying from an ergonomics point of view if a private field on a base class prevented a similarly named public...

> I don't believe this to be a web compatibility issue, however. _Not_ throwing an error shouldn't make any existing code break today, though it would be worthwhile to discuss...

While I'm still not a fan of `toKey`, if `coerce` is going to cause more confusion it would not be terrible to end up with `toKey`. I'd still prefer another...

> Could somebody first help me to understand the problem of `toKey`? Thank you. My problem with it is that there are other things that such an operation might plausibly...

> `data` is now reference-able inside the `else`, which is one of the things that this proposal is trying to "avoid". Oh, that was definitely not obvious to me; maybe...

There are multiple falsy values in JS, and it seems plausible that one might want to distinguish between them. But I don't necessarily have an opinion on that, just, since...

@ljharb Presumably yes to both; the language does not have a concept of an `else if` and the `else` following an `else if` belongs to the inner `if` rather than...

Again, this seems like something which belongs in its own issue. I opened #3 to track. I continue to believe this difference from C++ ought to be called out in...