Trotyl Yu

Also, there's a `cdkObserveContent` directive in the CDK should be able to help with this situation: https://material.angular.io/cdk/observers/overview

@tracker1 The publication edition of a proposal can be found at https://github.com/tc39/proposals/blob/master/finished-proposals.md.

@hax The module getter won't be hoisted as well, consider: ```javascript let foo = 42; export get f() { return foo; } ``` It will be an early error when...

> without hoisting function declarations, there is no reason to support circular dependency modules because you will just get TDZ or undefined @hax There could be non-eager usage, like: ```javascript...

> I assume export get f hosited same as `export function f`. @hax A reason that module getter cannot be hoisted is the computed "property" name, like: ```javascript const t1...

> An important requirement of ES modules is support modularizing existing codes. In a real-life JavaScript application (even before es6), most invocations happen in callbacks, like event handlers, schedulers, etc....

> That would remove the ability of creating "register" decorators - that is a decorator that commits its wrapped function to a global register on module import for example @Alphare...

@iddan Regarding the first one, there's already an decorator proposal for function expressions (at [stage-0-proposals](https://github.com/tc39/proposals/blob/master/stage-0-proposals.md) but no repo given), would it be better to contact the current champion first?

@lazaridis-com At least remove: > Angular generates warnings for these two lines as it sanitizes them as Angular won't generate warning for one of them, it's a fact, not an...

Duplicate of #18567