object getters return type error
lqzhgood opened this issue · comments
type T = {
data: {
a: number;
};
};
const b: T = {
data: {
a: 123123,
b: 3444, // throw type error
},
};
const c: T = {
get data() {
return {
a: 123,
b: 333, // not throw type error
};
},
};
const d = {
get data() {
return {
a: 123,
b: 333
};
},
};
type td = typeof d; // { a:number, b:number }
c.data.b
not throw type error seems to be a mistake ?
See https://github.com/microsoft/TypeScript/wiki/FAQ#indirect-excess-properties-are-ok
bug b.data.b
throw type error. and in c.data
no type prompt like any
,
see typescirpt palay
Sigh... I really wish the wording of this error message would be changed.
This isn't a bug. The excess property check error is not a type error, it's a lint check. You can't rely on it to prevent extra properties from being put on an object because it won't always trigger (which is by design). If that's what you need, see #12936.
The other issue you linked to this (#49511) is unrelated - there is nothing like an any
involved here. { a: number, b: number }
is a legal subtype of and assignable to { a: number }
.
Indirect excess properties are not an error. Examples of indirect excess properties would be:
- values returned by functions
- values stored in intermediate variables
b
is direct. You go straight from value→property.
c
in indirect because it is one step removed. You have a getter, which is a function that returns a value.
From the linked FAQ, excess property checks are to defend against things like typos:
const p: Dimensions = {
width: 32,
height: 14,
depht: 11 // <-- typo!!
}
But there are plenty of situations where you want or need to allow extra properties.
Sigh... I really wish the wording of this error message would be changed.
This isn't a bug. The excess property check error is not a type error, it's a lint check. You can't rely on it to prevent extra properties from being put on an object because it won't always trigger (which is by design). If that's what you need, see #12936.
The other issue you linked to this (#49511) is unrelated - there is nothing like an
any
involved here.{ a: number, b: number }
is a legal subtype of and assignable to{ a: number }
.
The focus of this issue is not on whether additional attributes can be added,
Is difference types of b.data
and c.data
by use getters
b.data
and c.data
should throw errors simultaneously or not
Indirect excess properties are not an error. Examples of indirect excess properties would be:
- values returned by functions
- values stored in intermediate variables
b
is direct. You go straight from value→property.
c
in indirect because it is one step removed. You have a getter, which is a function that returns a value.From the linked FAQ, excess property checks are to defend against things like typos:
const p: Dimensions = { width: 32, height: 14, depht: 11 // <-- typo!! }But there are plenty of situations where you want or need to allow extra properties.
Thank you for your answer, but c.data
look like any
in autocomplete.
You are conflating two different things. The autocomplete thing is unrelated to the type checking of c.data
.
b.data
andc.data
should throw errors simultaneously or not
No, they shouldn't; it's already been explained several times why c.data
doesn't have an error. The excess property check doesn't apply to it, but it's still type-checked properly. For example if you change the code to
const c: T = {
get data() {
return 42;
},
};
then you get a type error.
You are conflating two different things. The autocomplete thing is unrelated to the type checking of
c.data
.
b.data
andc.data
should throw errors simultaneously or notNo, they shouldn't; it's already been explained several times why
c.data
doesn't have an error. The excess property check doesn't apply to it, but it's still type-checked properly. For example if you change the code toconst c: T = { get data() { return 42; }, };then you get a type error.
Thank you, I understand my mistake
The real problem should be automatic completion
The problem of automatic completion made me think that c.data
had changed to any
type, resulting in the loss of type checking
In that case, this is a retroactive duplicate of #58484 😄