Discuss side-effects

Follow up to the conversation at #814.

@xtuc wrote :
> Ok I didn't know about that. I haven't heard about issues with the array replacer. To me that's safe enough, but a user has no way to know/debug that.
>
> I'm wondering if we shouldn't introduce flags, like GCC's -O1 to -Os or warning like in #570

@fathyb wrote :
> I second both, I think we should warn the user by default and then use multiple optimization level options to silent the warnings and choose if we should assume side effects.
>
> We could also offer the user to annotate its calls using comments, [à la Closure](https://github.com/google/closure-compiler/wiki/Annotating-JavaScript-for-the-Closure-Compiler). Something like :
>
> ```js
>
> /** @babel:side-effect **/
> function foo() {
> sideEffectApi()
> }
>
> /** @babel:side-effect:expression:bar() **/
> const dontTrim = bar()
> ```
>
> The is also the [`sideEffects` proposal](https://github.com/webpack/webpack/tree/master/examples/side-effects) from Webpack which may be handy, although I think we're not module aware.
>
> I feel like this needs its own discussion, perhaps I should open an issue?

@vigneshshanmugam wrote :
> Yeah totally agree, lets create a separate issue and discuss different methods there.

cc @devongovett for new scope-hoisting in Parcel, related parcel-bundler/parcel#1104

Start by reading issue #814 and the linked Webpack side-effects proposal, then compare the warning, optimization-level, and annotation ideas raised here. Done would require an agreed, concrete scope for handling side effects and user controls; this issue names no files or tests.

Written by the indexing model from the issue text.