Overload not typing object literals
shouldn’t only “real” show up as a property here? if not, how could I achieve that?
53 Replies
apologies for the shitty screenshot I’m on my mom’s laptop rn lmfao
Based on the documentation, it seems like you're asking about TypeScript's type inference and how it interacts with object literals and function overloads. However, without a specific code example, it's difficult to provide a precise answer.
In general, TypeScript uses static types and type inference to determine the properties and methods available on an object. If you're seeing unexpected properties, it might be due to the way your types or interfaces are defined.
If you're working with function overloads, the order of the overload signatures is important. TypeScript will use the first matching overload definition.
If you could provide a specific code example, I could give a more accurate answer. 🦕
I did provide a code example
???
lines 7 through 18
bro it's AI. AI can't read your screenshot
oh lmao what
I thought someone came in and ran a command or something
here's the code example sir since you cannot read screenshots
I would have expected only the
real property to show up in the object literal, since that's the overload I've chosen from true. If I type fake, it errors out.The behavior you're seeing is due to TypeScript's structural typing system. When you call
A(true, {...}), TypeScript doesn't immediately know which overload to pick. It sees that both Real and Fake are objects and that they could potentially match the object literal you're providing. Therefore, it suggests both real and fake properties.
However, once you start typing the object literal, TypeScript can start narrowing down which overload is correct. If you type { real: ... }, it will match the Real overload, and if you type { fake: ... }, it will match the Fake overload. If you provide a property that doesn't match the overload you're trying to use (like using fake when real is true), TypeScript will give an error.
If you want to avoid this, you could make your types more distinct so TypeScript can tell them apart more easily. For example, you could add a required type field to your Real and Fake types:
Now, TypeScript can tell the difference between Real and Fake as soon as you start typing the object literal, and it will only suggest the correct properties.why can't it tell which object to use from the boolean? it explicitly states which object goes with what
The TypeScript compiler doesn't evaluate the actual values of the arguments when determining which overload to use. Instead, it looks at the types of the arguments. In your case, the
real argument is of type boolean, which could be either true or false. Therefore, TypeScript considers both overloads as potential matches.
When you're calling the function A(true, {...}), TypeScript doesn't immediately know which overload to pick based on the true value. It sees that both Real and Fake are objects and that they could potentially match the object literal you're providing. Therefore, it suggests both real and fake properties.
However, once you start typing the object literal, TypeScript can start narrowing down which overload is correct. If you type { real: ... }, it will match the Real overload, and if you type { fake: ... }, it will match the Fake overload. If you provide a property that doesn't match the overload you're trying to use (like using fake when real is true), TypeScript will give an error.
This behavior is due to TypeScript's structural typing system. It's not about the actual values, but about the types of the values.by this logic, shouldn't this be able to tell which object to use based on whether the type is a boolean or string?
In your code example, TypeScript will indeed be able to determine which overload to use based on whether the
version argument is a string 'V2' or a boolean.
When you call A('V2', {...}), TypeScript knows to use the V2 overload, and it will only suggest the v2 property when you start typing the object literal. If you provide a property that doesn't match the V2 type (like using v3), TypeScript will give an error.
Similarly, if you call A(true, {...}) or A(false, {...}), TypeScript knows to use the V3 overload, and it will only suggest the v3 property when you start typing the object literal. If you provide a property that doesn't match the V3 type (like using v2), TypeScript will give an error.
This is because TypeScript uses the types of the arguments to determine which overload to use. In this case, the types are distinct ('V2' is not a boolean), so TypeScript can tell the overloads apart based on the version argument.except I can see both v2 and v3 as properties in intellisense
The behavior you're seeing is due to TypeScript's structural typing system. When you call
A('V2', {...}), TypeScript doesn't immediately know which overload to pick. It sees that both V2 and V3 are objects and that they could potentially match the object literal you're providing. Therefore, it suggests both v2 and v3 properties.
However, once you start typing the object literal, TypeScript can start narrowing down which overload is correct. If you type { v2: ... }, it will match the V2 overload, and if you type { v3: ... }, it will match the V3 overload. If you provide a property that doesn't match the overload you're trying to use (like using v3 when version is 'V2'), TypeScript will give an error.
This behavior is due to TypeScript's structural typing system. It's not about the actual values, but about the types of the values.but you said
it will only suggest the v2 propertyI apologize for the confusion. The TypeScript compiler uses the types of the arguments to determine which overload to use. However, when it comes to providing suggestions via Intellisense in your code editor, it might still show all possible properties from all overloads until you start typing and it can infer the correct type. This behavior can vary depending on the code editor and its TypeScript support.
In your case, even though you've specified 'V2' or boolean as the argument, the editor's Intellisense might still show both
v2 and v3 properties as it doesn't evaluate the actual values of the arguments. Once you start typing the object literal, TypeScript can start narrowing down which overload is correct.
Please note that this is a limitation of the editor's Intellisense and not TypeScript's type system. The TypeScript compiler itself will correctly match the overloads based on the provided arguments when the code is compiled.I am probably gonna start a robot revolution if I keep bugging this AI 
another question: is it possible to remove every
another question: is it possible to remove every readonly component on a type?