Spread of set into object not detected as type error

[cmtm]

Bug Report

A spread of a Set into an object is assignable to a Set. This shouldn't be allowed, because the object isn't a Set. tsc should be able to detect this at compile time.

🔎 Search Terms

set spread

🕗 Version & Regression Information

This is the behavior in the version I tried (3.3.3, 4.6.2, 5.0.4, 5.1.0-dev.20230411), and I reviewed the FAQ for entries about Common "Bugs" That Aren't Bugs

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about Sets and spreads

⏯ Playground Link

Playground link with relevant code

💻 Code

const my_set1: Set<number> = new Set();
// The type of my_set2 is actually Object.
// tsc doesn't detect this, and thinks it's a `Set<number>`.
const my_set2: Set<number> = {...my_set1};

// This will fail at runtime because my_set2 isn't a Set.
my_set2.has(2);

🙁 Actual behavior

tsc doesn't detect the type error.

🙂 Expected behavior

tsc should detect the type error.

[fatcerberus]

This is a more general limitation than implied - { ...new A() } (for some class A) likewise isn’t an A, but TS thinks it is because structural typing. I'm thinking this will probably be considered a design limitation and not a bug.

Playground

class U {
    foo = "fooey";
    bar = "bard";
}

const notU = { ...new U() };
const u: U = notU;
console.log(u instanceof U);  // false, oops

[RyanCavanaugh]

Yeah, { ...x } is always assumed to be the same type of x. Non-enumerability isn't tracked anyway, and expanding it out into { a: x.a, b: x.b, c: x.c } etc breaks a bunch of scenarios that people rightly expect to work.

[MartinJohns]

Non-enumerability isn't tracked anyway

Related: #9726