Verbose computed property transpilation

[falsandtru]

TypeScript Version: 2.7.0-dev.201xxxxx

Search Terms:

Code

const p1 = 0;
const p2 = 1;
class A {
  [p1] = 0;
  [p2]() {}
}

Expected behavior:

const p1 = 0;
const p2 = 1;
class A {
    constructor() {
        this[p1] = 0;
    }
    [p2]() { }
}

Actual behavior:

const p1 = 0;
const p2 = 1;
class A {
    constructor() {
        this[_a] = 0;
    }
    [(_a = p1, p2)]() { }
}
var _a;

Playground Link:

Related Issues:

[falsandtru]

Valid code but some build tools can't parse this code.

[DanielRosenwasser]

Out of curiosity, which tools?

[falsandtru]

Here: https://github.com/power-assert-js/karma-espower-preprocessor (https://github.com/power-assert-js/power-assert)

And error:

  {
    "message": "Expected ']'\nat .../spica/dist/spica.js:1818:6 <- dist/spica.espowered.js:3662:25",
    "str": "Expected ']'\nat .../spica/dist/spica.js:1818:6 <- dist/spica.espowered.js:3662:25"
  }

Probably someone in the dependencies of https://github.com/power-assert-js/espower-source or browserify.

I'm avoiding this issue as this:

const p1 = 0;
const p2 = 1;
class A {
  [p2]() {}
  [p1] = 0;
}

[falsandtru]

@weswigham Please also fix this if possible.

[weswigham]

Erm, we'd have to walk back other spec/correctness fixes (which were requested) to change this. I'm not sure we want that, given the current downleving is pretty much the only valid way to do it (and still actually use a class keyword), per spec. @rbuckton do you have an opinion here?

[falsandtru]

My expected code is not enough?

[rbuckton]

This emit is necessary to preserve the correct runtime semantics and order of operations as they apply to ECMAScript classes. Consider the following:

class A extends expr1 {
  [expr2] = 0;
  [expr3]() {}
}

Per the class fields proposal and the ECMAScript spec, the correct order of operations is:

1. Evaluate expr1
2. Evaluate expr2
3. Evaluate expr3
4. Evaluate class A extends ...

We would have two ways to address this:

• Inline evaluation:

  class A extends expr1 {
    constructor() {
      this[_a] = 0;
    }
    [(_a = expr2, expr3)]() {}
  }
  var _a;

• Ahead-of-time evaluation:

  _a = expr1;
  _b = expr2;
  class A extends _a {
    constructor() {
      this[_b] = 0;
    }
    [expr3]() {}
  }
  var _a, _b;

Inline evaluation is perfectly valid JavaScript, and is our current emit behavior. Ahead-of-time evaluation is also valid, but introduces additional temporary variables. We could, in theory, partially remediate this if we are able to determine that expr2 and expr3 are both Identifier and refer to const lexical declarations (such that the value cannot change between invocations of the constructor). However, if expr1 is a more complex expression, then you would be back to the same issue.

Regardless as to whether we opt to make any changes here, I would recommend filing an issue against the related build tool as it seems to be unable to parse valid JavaScript here.

[falsandtru]

I understood. The property keys in my expected code can't be generalized to expressions. I vote for Ahead-of-time evaluation because of its clearness and readability.

[Kingwl]

seems fixed in #23956

https://github.com/Microsoft/TypeScript/pull/23956/files#diff-da131db8180ab25979d1adb67e90c6b3R9