Repository navigation
Can assign types even though interface field overriden using Omit #36604
Description
TypeScript Version: 3.7.5
Search Terms:
Omit field override intersection assign missing error
Expected behavior:
If I use Omit and an intersection to override a field within an interface, when I assign an object of new type to original type I am expecting that typescript would give an error.
For example, in the example below, I expect to see a compile error in the line x = v;
But unfortunately there isn't.
However, assigning the field explicitly between the 2 types does give an error.
Playground Link: Provided
Actual behavior:
Code
interface To {
field?: number;
anotherField: string;
}
type From = { field: null } & Omit<To, 'field'>
function foo(v: From) {
let x: To;
x = v; // expect to have an error but there isn't
x.field = v.field; // Type 'null' is not assignable to type 'number | undefined'
}
Compiler Options
{
"compilerOptions": {
"noImplicitAny": true,
"strictNullChecks": true,
"strictFunctionTypes": true,
"strictPropertyInitialization": true,
"strictBindCallApply": true,
"noImplicitThis": true,
"noImplicitReturns": true,
"useDefineForClassFields": false,
"alwaysStrict": true,
"allowUnreachableCode": false,
"allowUnusedLabels": false,
"downlevelIteration": false,
"noEmitHelpers": false,
"noLib": false,
"noStrictGenericChecks": false,
"noUnusedLocals": false,
"noUnusedParameters": false,
"esModuleInterop": true,
"preserveConstEnums": false,
"removeComments": false,
"skipLibCheck": false,
"checkJs": false,
"allowJs": false,
"declaration": true,
"experimentalDecorators": false,
"emitDecoratorMetadata": false,
"target": "ES2017",
"module": "ESNext"
}
}
Activity
ilogico commentedon Feb 4, 2020
It's funny, you can get the correct behavior with:
ekilah commentedon Apr 1, 2020
thanks for this, just ran into it as well. playground link
seems to be solved by switching to the
Nightlybuild of TS which I assume includes the changes in the 3.9 beta, which claims to have this fixed via #37195seems like one step closer to fixing gaps between types and interfaces, like I brought up in #24970