Ranando D Washington-King

Please don't obfuscate the meaning of what I said. I'm saying that developers who haven't read and understood the fine details of this proposal are likely to think that these...

@nicolo-ribaudo > I think that it's clear: class fields are outside of the constructor's braces. Currently things inside {} are not accessible from the outside (except for hoisted vars inside...

@shannon have a read through the last few posts of #253. [@bakkot answered that question there](https://github.com/tc39/proposal-class-fields/issues/253#issuecomment-543440522).

@bakkot I know it's been discussed to death, that's why I'm not going to argue with you. However, if at all possible, I would like an explanation. From the FAQ:...

@ljharb > think your questions are about “why would seeing this.x make someone think it’s private” Um, no. My question is exactly as I stated it. It's about why "`private...

@ljharb > i don't think people think about public/private in that way. So to be clear, it's just an assumption?

@redradist > Disagree with you, because if you say why private x should cause a.x to refer to private access, then why a.x can always cause to return undefined, but...

@ljharb IMO, assumptions have their use. Justification is not among them. This is even more true when designing a very popular, widely used language. But maybe that's just me.

@trusktr Unfortunately, that would introduce confusion in the extreme. To make something like that work, a `class` wouldn't be allowed to have both `private x` and `#y`. You'd be forced...

@ljharb > "I successfully keep you from snatching it away" would require also denying me any means of reflection, which is indeed what "hard private" means. On this, we agree,...