3 ms·

foo() + 1 ESInfer complains about this because you are adding a string with a number, which sometimes will result in an unexpected value in runtime, and you ha

foo() + 1 ESInfer complains about this because you are adding a string with a number, which sometimes will result in an unexpected value in runtime, and you hardly find it out. So ESInfer, on purpose, disallows this kind of type casting automatically. As for the error message: > expecting possible candidates all failed: candidate number failed: expecting number but got string. candidate string failed: expecting string but got number. but got number. It's saying two possible situations: #1 number + number and #2 string + string are all failed, which is precisely the error. However, this may be a lack of readability if someone is the first time using ESInfer. I'll write some wikis on how to read error messages efficiently as a starting point and, finally and hopefully, evolve a better error reporting system. So if you ask me how to deal with this kind of code with ESInfer, I'd suggest making the compiler happy by converting the string to a number or the number to a string. (BTW, try to use the format as suggested, hope it works :D)

bastawhiz 4y ago
I think the parent is raising the point that knowing that there's a problem is only half of the issue you need to solve. Being able to assert that certain types only appear in certain places is still important: if I pass the wrong type as a function argument, I don't know whether there's a bug somewhere upstream where that data came from, or whether there's a bug in the function where I'm using a parameter incorrectly. Or if I'm not returning where I should be, or returning where I shouldn't be.
- jiangmy 4y ago
  Did you mean something like an error stack? That'll be significantly helpful if the last error is not apparent enough to solve the error. I'll investigate this and see if there's any performance impact on the inferring process.
hermanradtke 4y ago
TypeScript can infer all the types but it still requires the coder to specify types in certain places because of the exact issue that is being shown here. The types create an API contract that keeps errors localized. ESInfer raises an error at the call site, which is harder to understand what is going on. Also, lack of types will cause the API contract to suddenly change in unexpected ways. I commend you for creating ESInfer, but there is a reason this approach is usually not taken.

bastawhiz 4y ago

I think the parent is raising the point that knowing that there's a problem is only half of the issue you need to solve. Being able to assert that certain types only appear in certain places is still important: if I pass the wrong type as a function argument, I don't know whether there's a bug somewhere upstream where that data came from, or whether there's a bug in the function where I'm using a parameter incorrectly. Or if I'm not returning where I should be, or returning where I shouldn't be.

jiangmy 4y ago
Did you mean something like an error stack? That'll be significantly helpful if the last error is not apparent enough to solve the error. I'll investigate this and see if there's any performance impact on the inferring process.

hermanradtke 4y ago

TypeScript can infer all the types but it still requires the coder to specify types in certain places because of the exact issue that is being shown here. The types create an API contract that keeps errors localized. ESInfer raises an error at the call site, which is harder to understand what is going on. Also, lack of types will cause the API contract to suddenly change in unexpected ways. I commend you for creating ESInfer, but there is a reason this approach is usually not taken.