michaelficarra / CoffeeScriptRedux

:sweat: rewrite of the CoffeeScript compiler with proper compiler design principles and a focus on robustness and extensibility

Home Page:https://michaelficarra.github.com/CoffeeScriptRedux/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Property access should not be treated as dead code.

pygy opened this issue · comments

Currently, the compiler will drop a property access whose return value is not used.

a.b # --> nothing

The thing is, because of ES5 accessors (and moreover ES6 proxies), property access may have side effects. They should not be eliminated.

commented

Duplicate of #76.

This is expected behaviour. CoffeeScript has a long history of ignoring the existence of getters.

The trouble is it means that you can't interact cleanly with JS code that relies on that feature.

commented

You can with a.b, I guess.

Not terribly efficient I guess but would this be an acceptable workaround? Last I checked CSR didn't support back ticks, so...

use = ->
use a.b

That's what I meant by "not cleanly".

Furthermore, a future, smarter compiler may also eliminate use calls, which are no ops, not matter what.

It'd be kind of difficult to eliminate that call since the compiler can't be sure that the value of use itself hasn't changed. Anyways, looks like I was mistaken about the status of the backtick in redux—pretty sure it used to be a syntax error, but it works now—so if you prefer that solution, it's there.

It'd be kind of difficult to eliminate that call since the compiler can't be sure that the value of use itself hasn't changed.

Since CoffeeScript is lexically scoped, the compiler has all the information needed to determine if a variable is rebound later on. In that case, if the evaluation of the arguments dont have any effect, removing the call is a valid optimization. Relying on the lack of a correct optimization to prevent an invalid one is probably not a good idea...

That being said, I agree that relying on the side effects of property access is a bad programming
practice, I just wanted to be sure it wasn't an oversight.

Well, it could have its use in a well documented DSL, but it's a corner case.

The backticks allow it if needed, so it isn't that problematic if the language doesn't support it anyway.

As far as I knew, backticks had been removed from CS 2.0.

I'm glad that they're back in. In this case it makes it explicit that the property access does something special, so if someone encounters foo.bar, it means that something special is occuring.

Backticks weren't removed, they just aren't able to introduce invalid syntax, such as {. And your conclusion was correct: we don't acknowledge side-effecting getters. It is a deplorable design.

As a workaround, you can simply assign the result to a variable (no need to pass it to an identity function). But I generally agree that getters are dumb and anti-js.

Side-effecting getters.