Rule semicolon is behaving inconsistently/unexpectedly

[mnn]

Bug Report

• TSLint version: 4.3.1
• TypeScript version: 2.1.4
• Running TSLint via: CLI

TypeScript code being linted

// using "semicolon": [true, "always"]
// actually doesnt mean it requires semicolon in all
// common positions (e.g. every field - just some fields).

class A {
  a = 0; // <- not reported
}

class B {
  b = () => ({b: 0}); // <- not reported
}

class C {
  c = () => ({
    c: 0
  }); // <- reported, WTH? It is same as a case B...
}

class D {
  d() {
    return 0;
  } // <- not reported (which is fine IMO)
}

with tslint.json configuration:

...
    "semicolon": [true, "always"],
...

Actual behavior

C case is reported (Unnecessary semicolon).

Expected behavior

C case should not be reported. Or both fields with arrow function should be reported (B and C), but it would be IMO inconsistent, since other fields (case A) are not being reported.

[adidahiya]

See relevant discussion here: #1949 (comment)

My assessment and (accepted) proposal:

Right now the "always" option mostly just enforces the existence of semicolons in certain positions and only disallows semicolons in one position. The semantics could use some cleaning up; perhaps the reporting of "unnecessary" semicolons belongs in another rule option?

[bumbleblym]

the typescript spec https://github.com/Microsoft/TypeScript/blob/master/doc/spec.md requires that

• type alias declarations are terminated with a semicolon
• object type members are separated by semicolons or commas; the last semicolon/comma is optional.

the compiler behaviour is considered(?) to be buggy: microsoft/TypeScript#10730

the semicolon rule applies to both cases, while the trailing-comma rule affects the second case: #1810

my proposal is to have semicolons/trailing-comma apply to statements and not type declarations, and add the following rule:

"object-type-member-separator": [true, "semicolon"]
"object-type-member-separator": [true, "comma"]
"object-type-member-separator": [true, "semicolon", no-final-separator"]

which would result in a breaking change.

[foxel]

What's the resolution here?

[ajafff]

#3294 added a strict-bound-class-methods option that was released with tslint 5.8.0