Repository: TypeScript
Issue: A flag to make TypeScript more strict towards duck-typing classes
Labels: Suggestion,Awaiting More Feedback

# Suggestion

<!--
  Please fill in each section completely. Thank you!
-->

## 🔍 Search Terms

<!--
  💡 Did you know? TypeScript has over 2,000 open suggestions!
  🔎 Please search thoroughly before logging new feature requests as most common ideas already have a proposal in progress.
  The "Common Feature Requests" section of the FAQ lists many popular requests: https://github.com/Microsoft/TypeScript/wiki/FAQ#common-feature-requests

  Replace the text below:
-->

JavaScript class, TypeScript interface, duck-typing, anonymous object

## ✅ Viability Checklist

<!--
   Suggestions that don't meet all these criteria are very, very unlikely to be accepted.
   We always recommend reviewing the TypeScript design goals before investing time writing
   a proposal for ideas outside the scope of the project.
-->
My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).


## ⭐ Suggestion

I think it might be useful if TypeScript didn't always treat classes same as interfaces. For example, I'd like to see at least a warning when assigning a compatible anonymous object to a variable of a known `class` type, like this ([Playground link](https://www.typescriptlang.org/play?#code/MYGwhgzhAEDC0G9oQFzIC4CcCWA7A5tALzQBEpA3NAL4BQwA9rhOtA2vCUqmQIwBMAZlI0K9JhAYgApgDoQDfAAoGsiAEoxjZlLkLlDaHhZhcwaQwBmcTdAD0d6JbAgI08TpnzFK2dpaYAK7A6AyYsrhgALbStg7QAPIARgBW0iG0QA)):

```TypeScript
class C { s: string = ""; }
const o: C = { s: "123" };
console.log(o.s);
console.log(o instanceof C); // false
console.log(o.constructor.name); // Object
```

## 📃 Motivating Example

<!--
  If you were announcing this feature in a blog post, what's a short explanation that shows
  a developer why this feature improves the language?
-->

The above code compiles without any warnings, which may come as a surprise for people coming from other OOP languages, and potentially cause runtime errors.

Unlike TypeScript interfaces, classes are still "first-class citizens" in JavaScript. I believe they're are essential part of JavaScript, and their value as types should rather be elevated by TypeScript, than diminished. This might help people coming to TypeScript from other languages (like C#, Java and even JavaScript itself!) who extensively have used classes before.

In this light, the author of that code fragment probably meant to write something that looks like below ([Playground link](https://www.typescriptlang.org/play?#code/MYGwhgzhAEDC0G9oQFzIC4CcCWA7A5tALzQBEpA3NAL4BQwA9rhOtA2vCQPIBGAVgFNg6AHSQI2fLgAUuAQHc40gJQAaRMjSkAjACYAzKRrKK9JhAYgBIkA3zSGIiCbPNL12-YbQ8LMLmABBgAzOBNoAHoI6CwAVwFXCysbOwcRRmY44QZMEVwwAFsBcKi4WiA)). It'd be great if TypeScript introduced a CLI option to assist with spotting cases like that.

```TypeScript
class C { s: string = ""; }
const o: C = Object.assign(new C(), { s: "123" });
console.log(o.s);
console.log(o instanceof C); // true
console.log(o.constructor.name); // C
```

On a side note, if I do this ([Playground link](https://www.typescriptlang.org/play?ssl=1&ssc=1&pln=4&pc=34#code/MYGwhgzhAEDC0G9oQFzIC4CcCWA7A5tALzQBEpA3NAL4BQwA9rhOtA2vCbgKYDucACgCUFekxZsATB2LQe-BgDpGzLAFdg6BpmGiVEBiG6KQDfAIaTl49Zu2LcYALbcRQA)):

```TypeScript
class C { s: string = ""; }
const o: C = new C();
const o2: C = new o.constructor();
console.log(o2.constructor.name);
```

I don't understand the warning `"This expression is not constructable. Type 'Function' has no construct signatures.(2351)"` for the `const o2: C = new o.constructor()` line. It looks perfectly valid to me, the class type should be deductible in the above code fragment. 

I can think of `const o2: C = new (o.constructor as {new(): C})()` as a workaround, or `const o2: C = new (o.constructor as any)() as C`. I don't like either, because at least the base class type for `o` is already known in this lexical scope, it's `C`.

## 💻 Use Cases

I hope I've covered that with the second code fragment, but also please see @Barbiero's [comment](https://github.com/microsoft/TypeScript/issues/42698#issuecomment-775614111) below. Thanks for considering this idea.