Sam Goto

> Of course it does, because you used call({c:1}), but this feature cannot assume that such a thing > will always work: if b is an arrow function or the...

(oops, sorry for closing/reopening, pressed the wrong button)

Just reporting back on this thread here with what I think was forward progress made in this [thread](https://github.com/samuelgoto/proposal-block-params/issues/20#issuecomment-347338360). I'm generally in agreement with the desire to move away from the...

Similar discussion here too: https://github.com/samuelgoto/proposal-block-params/issues/21#issuecomment-347964929

That's pretty awesome, thanks for kicking this off! Give me a couple of days to digest this and factor this in (I'll be ooo next week for Thanksgiving so will...

Wow, lots of good stuff in this alternative exploration. Let me try to unpack and discuss piece by piece (not sure what's the best way to do this, but lets...

Lots of good observations again, let me try to break things down and comment things separately. > One last thing: the control flow side of things can easily be punted...

I'm getting increasingly excited about the approach that I outlined because it addresses a consistent feedback that I've been getting that messing with ```this``` isn't a great idea. I tried...

> I'm going to update the text of the proposal to reflect this formulation done. https://github.com/samuelgoto/proposal-block-params https://gitpitch.com/samuelgoto/proposal-block-params

> Yeah we modify the parser and make a new babel plugin just like for another proposal such as numeric separators FWIW, here is a really crappy implementation with an...