Skip to content
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

Object spread unsound w.r.t. width subtyping of object types #15454

Closed
samwgoldman opened this issue Apr 28, 2017 · 6 comments
Closed

Object spread unsound w.r.t. width subtyping of object types #15454

samwgoldman opened this issue Apr 28, 2017 · 6 comments
Labels
Design Limitation Constraints of the existing architecture prevent this from being fixed

Comments

@samwgoldman
Copy link

TypeScript Version: Whatever is running on TypeScript Playground

Code

var o1: { p: string, q: number } = { p: "", q: 0 };
var o2: { p: string } = o1;
var o3: { p: string, q: string } = { q: "", ...o2 };

Expected behavior:

Some type error somewhere. o3 has type {p: string, q: number} at runtime, but we think q has type string.

Actual behavior:

No error. Potential runtime type error.

@RyanCavanaugh RyanCavanaugh added the Needs More Info The issue still hasn't been fully clarified label Apr 28, 2017
@RyanCavanaugh
Copy link
Member

"somewhere" is doing a lot of work there 😉 . Where specifically should the error be (and by what process)?

@samwgoldman
Copy link
Author

samwgoldman commented Apr 28, 2017

Hah, fair! I thought the example was small enough to make it clear :)

One option would be to forbid width subtyping between object types, so the error would be on line 2. This is pretty limiting, so not a great option.

Another option would be to error on line 3. Because the q property of o2 could be anything as far as TS knows, you could infer the type of the spread to be { p: string, q: {} }, which would be incompatible with { p: string, q: string }.

@RyanCavanaugh
Copy link
Member

Without closed types, that's effectively the same as "don't allow spreading, ever", which doesn't really seem helpful.

@samwgoldman
Copy link
Author

samwgoldman commented Apr 28, 2017

Just confirming this is by design. (I agree this is a reasonable tradeoff to make, FWIW)

@RyanCavanaugh RyanCavanaugh added Unactionable There isn't something we can do with this issue Design Limitation Constraints of the existing architecture prevent this from being fixed and removed Needs More Info The issue still hasn't been fully clarified Unactionable There isn't something we can do with this issue labels Apr 28, 2017
@RyanCavanaugh
Copy link
Member

Yep

@mhegazy
Copy link
Contributor

mhegazy commented May 19, 2017

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.

@mhegazy mhegazy closed this as completed May 19, 2017
@microsoft microsoft locked and limited conversation to collaborators Jun 14, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Design Limitation Constraints of the existing architecture prevent this from being fixed
Projects
None yet
Development

No branches or pull requests

3 participants