Ben Lickly

I don't think there's an existing suppression for that error, since in the common case it was warning about something that is also a VM error.

This definitely sounds like a safe optimization to make. Unfortunately, there are so many safe optimziations that would improve code-size that we don't generally have time to act on them...

Thanks for the report.

Added Chad in case he has an opinion.

Exciting! Created internal issue: http://b/127859638

The proposal is still a stage 3 proposal, i.e. not yet part of a language standard, but the current assumption (I think) is that it will become part of ES2020

Agreed, I'm just responding to the question of which language version it will be in (i.e. not ES2017)

@helenlpang is currently working on support for *public* fields (both static and non), but `#private` fields will unfortunately have to wait until after that is done.

Related discussion: https://groups.google.com/g/closure-compiler-discuss/c/lIGMmsWJtB0 Personally, I forgot that type-checking wasn't enabled by default in SIMPLE mode

This is easy to repro: https://closure-compiler-debugger.appspot.com/#input0%3Dexport%2520class%2520A%2520%257B%257D%250Aexport%2520default%2520%257BA%257D%26input1%3Dimport%2520%257BA%257D%2520from%2520'.%252Finput0'%253B%250Aimport%2520collection%2520from%2520'.%252Finput0'%253B%250A%250Aclass%2520B%2520extends%2520A%2520%257B%257D%250Aclass%2520C%2520extends%2520collection.A%2520%257B%257D%26conformanceConfig%26externs%26refasterjs-template%26includeDefaultExterns%3Dtrue%26CHECK_TYPES%3Dtrue%26TRANSPILE%3Dtrue%26CLOSURE_PASS%3Dtrue%26PRESERVE_TYPE_ANNOTATIONS%3Dtrue%26PRETTY_PRINT%3Dtrue @jplaisted, Can you take a look?