Intersection type of abstract classes does not throw error if same member exists in multiple abstract classes · Microsoft/TypeScript#26617

(2 comments) (0 reactions) (0 assignees)TypeScript (48,455 stars) (6,726 forks)batch import

BugDomain: IntersectionHelp Wanted

Description

TypeScript Version: 3.0.1

Search Terms: "Intersection", "abstract"

Code

export type Constructor<T = {}> = new (...args: any[]) => T;

abstract class Outer1 {
  abstract same: number;
  abstract notSame: string;
}

abstract class Outer2 {
  abstract same: number;
}

function Mixin1<TBase extends Constructor>(Base: TBase) {
  abstract class Inner1 extends Base {   // Same as Outer1
    abstract same: number;
  }
  return Inner1;
}

function Mixin2<TBase extends Constructor>(Base: TBase) {
  abstract class Inner2 extends Base {   // Same as Outer2
    abstract same: number;
  }
  return Inner2;
}

function rollUp<T>(mixins): new (...args) => T {
  return mixins.reduce((acc, mixin) => mixin(acc), class Seed {});
}

class Example extends rollUp<Outer1 & Outer2>([Mixin1, Mixin2]) {
  // Compiler will throw error when "notSame" is unimplemented
  // Compiler DOES NOT throw error about non-implemented "same" member
}

Expected behavior: Compiler should say that same is not implemented in regular class

Actual behavior: Compiler does not throw error saying that same is not present in example class, despite throwing an error about notSame. It will throw an error, however, if the types of same are incompatible.

Playground Link: https://www.typescriptlang.org/play/#src=export%20type%20Constructor%3CT%20%3D%20%7B%7D%3E%20%3D%20new%20(...args%3A%20any%5B%5D)%20%3D%3E%20T%3B%0D%0A%0D%0Aabstract%20class%20Outer1%20%7B%0D%0A%20%20abstract%20same%3A%20number%3B%0D%0A%20%20abstract%20notSame%3A%20string%3B%0D%0A%7D%0D%0A%0D%0Aabstract%20class%20Outer2%20%7B%0D%0A%20%20abstract%20same%3A%20number%3B%0D%0A%7D%0D%0A%0D%0Afunction%20Mixin1%3CTBase%20extends%20Constructor%3E(Base%3A%20TBase)%20%7B%0D%0A%20%20abstract%20class%20Inner1%20extends%20Base%20%7B%20%20%20%2F%2F%20Same%20as%20Outer1%0D%0A%20%20%20%20abstract%20same%3A%20number%3B%0D%0A%20%20%7D%0D%0A%20%20return%20Inner1%3B%0D%0A%7D%0D%0A%0D%0Afunction%20Mixin2%3CTBase%20extends%20Constructor%3E(Base%3A%20TBase)%20%7B%0D%0A%20%20abstract%20class%20Inner2%20extends%20Base%20%7B%20%20%20%2F%2F%20Same%20as%20Outer2%0D%0A%20%20%20%20abstract%20same%3A%20number%3B%0D%0A%20%20%7D%0D%0A%20%20return%20Inner2%3B%0D%0A%7D%0D%0A%0D%0Afunction%20rollUp%3CT%3E(mixins)%3A%20new%20(...args)%20%3D%3E%20T%20%7B%0D%0A%20%20return%20mixins.reduce((acc%2C%20mixin)%20%3D%3E%20mixin(acc)%2C%20class%20Seed%20%7B%7D)%3B%0D%0A%7D%0D%0A%0D%0Aclass%20Example%20extends%20rollUp%3COuter1%20%26%20Outer2%3E(%5BMixin1%2C%20Mixin2%5D)%20%7B%0D%0A%20%20%2F%2F%20Compiler%20will%20throw%20error%20when%20%22notSame%22%20is%20unimplemented%0D%0A%20%20%2F%2F%20Compiler%20DOES%20NOT%20throw%20error%20about%20non-implemented%20%22same%22%20member%0D%0A%7D

Contributor guide

Tech stack: typescript
Domain: toolingdeveloper experience
Issue type: bug
Difficulty: 4
Estimated time: 1-2 days
Activity status: stale
Clarity: clear
Prerequisites: TypeScript type systemabstract classesintersection types
Newbie friendliness: 10
Research direction: The bug is that TypeScript's type checker does not report an error when a concrete class fails to implement an abstract member that appears in multiple abstract classes in an intersection type. The fix likely involves modifying the check for abstract member implementation in intersections. Start by examining the checker.ts file, specifically the functions that handle intersection types and abstract member enforcement (e.g., `checkAbstractClass`, `getIntersectionType`). Look for existing tests in `tests/cases/compiler/` related to abstract intersection types to understand expected behavior. The playground link (https://www.typescriptlang.org/play/#src=...) and the issue comments provide reproduction steps. Ensure that when two abstract classes have a common abstract member, the implementing class must provide that member. The current behavior incorrectly merges the declarations, so the member is considered implemented if both are abstract in the same way. A potential fix is to treat each abstract member from each abstract class as a separate requirement in the intersection, or to ensure that the check is performed on the intersection type as a whole.