kzc

> If we want consistent behaviour alongside pure_funcs, then the current behaviour is good as is. I'm leaning in that direction. When you think about it, the behavior is somewhat...

Change the [bug] label to [question]?

off topic: Some projects are using uglify `/*@__PURE__*/` annotations to great effect in the wild: [Angular Build Optimizer](https://github.com/angular/devkit/tree/master/packages/angular_devkit/build_optimizer) has been reported to significantly reduce app bundle sizes - by as...

And of course @Andarist added `/*@__PURE__*/` annotation support to downleveled ES5 classes in the upcoming Babel 7 release: https://github.com/babel/babel/commit/c47258d68c94839840f622014b5fe266ac2a59e2

@Andarist I appreciate that the pure annotation behavior with respect to ignoring side effects of `AST_Call.expression` seems strange and unexpected at first glance - it certainly was to me. But...

Be aware that I may not read the re-edits of past posts. > `/*#__PURE__*//*#__PURE__*//*#__PURE__*/fn()()()` The lack of output reversibility with respect to pure annotation comments is a known issue that...

> Do you mean that getters could be called here? Isnt there an option to assume pure getters? Yeah, getters or unset globals like debug or log statements that would...

It was the first option name that came to mind. Alternatives: `pure_annotate`, `pure_annotations`.

Or perhaps set a string value for `side_effects` similar to how `pure_getters` is overloaded. The `side_effects` default of `true` would retain current pure annotation behavior. I don't know what the...

Chrome no longer penalizes `1/0` over `Infinity`, but it's interesting to note that the benchmark runs 2.5X faster in Safari. The default is: ``` keep_infinity : false, ``` No harm...