Skip to content

Wrong assignability of class types from expressions with private fields #56146

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
dragomirtitian opened this issue Oct 18, 2023 · 3 comments
Closed
Labels
Design Limitation Constraints of the existing architecture prevent this from being fixed

Comments

@dragomirtitian
Copy link
Contributor

dragomirtitian commented Oct 18, 2023

πŸ”Ž Search Terms

class expression private fields assignability

πŸ•— Version & Regression Information

  • This is the behavior in every version I tried

⏯ Playground Link

Playground Link

πŸ’» Code

function makeClass(v: number) {
    return class C{
        #id = v;
        static getId(o: C) {
            return o.#id;
        }
    }
}

const cls1 = makeClass(1)
const cls2 = makeClass(2)

let c1 = new cls2(); // TS thinks this is ok
cls1.getId(c1) // runtime error different versions of #id

πŸ™ Actual behavior

c2 is assignable to c1 even though they contain private fields that are different (even if they come from the same source code)

πŸ™‚ Expected behavior

Instances of cls2 should not be assignable to cls1 since they have different versions of the private field.

Additional information about the issue

Found as I was exploring the consequences of #56145

@fatcerberus
Copy link

I'm thinking this is probably a design limitation (i.e. nominally-typed properties are distinguished by source location or something), but yeah, ouch, that's unfortunate.

@RyanCavanaugh RyanCavanaugh added the Design Limitation Constraints of the existing architecture prevent this from being fixed label Oct 18, 2023
@RyanCavanaugh
Copy link
Member

Yeah, there is zero concept of the kind of per-invocation tracking you'd need to handle this.

@jcalz
Copy link
Contributor

jcalz commented Oct 18, 2023

Reminds me of #37469, where each invocation of a function spits out a new nominal type.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Design Limitation Constraints of the existing architecture prevent this from being fixed
Projects
None yet
Development

No branches or pull requests

4 participants