[CS2] Remove support for bound instance methods

[connec]

Bound methods are implemented as assignments to this in the constructor. In derived classes, where this is unavailable until after super has been called, the binding is applied and assigned after the super call. This means that any references to ‘bound’ methods reachable from the parent constructor will actually point to the unbound prototype methods.

This can lead to very subtle bugs where a method that is thought to be bound is handed off and later called with an incorrect context, and the only defence is for users to be vigilant about referencing bound methods in constructors.

---

This is probably the most extreme solution to the problem, and would leave heavy users of bound methods with an unpleasant refactoring task, however the alternatives aren’t terribly appetising either:

• Restrict the error to derived classes only. A common use of bound methods is for event handlers in frontend frameworks such as Backbone and React, both of which rely on extending base classes. Choosing this approach would not help these users, and would make bound instance methods even more of a fringe feature.

• Hoist the entire method definition into the constructor, ensuring it isn’t assigned at all until super has been called. This would at least make any bugs easier to spot, and also looks very similar to the class public fields ECMA Stage 2 proposal. Matching some ES equivalent is probably the best strategy long term, but as this proposal is only Stage 2 we can’t rely on it not being changed.

• Leave everything as it is. We would could simply document the caveats of bound method interactions with super and let everyone figure it out.

Edit: #4512, #3093, and others propose a binding property access (as - @vendethiel would be quick to add - is available Coco/LS). This would make the necessary refactoring for this or option 1 slightly easier, and is also an ES proposal.

[GeoffreyBooth]

This looks good to me. @lydell, did you have any feedback? I assume you agree with this solution to #4497?

[lydell]

I think this looks good to me, too.

[xixixao]

Wait, shouldn't this compile to a property initializer?

class A
  b: => this.x

class A {
  b = () => this.x;
}

There is no way to get the above output or any equivalent now?

[xixixao]

@connec @lydell

[connec]

@xixixao property initializers are just a Stage 2 proposal, so there is no support for them currently.

The equivalent would be:

class A
  constructor: ->
    @b = => @x