You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, notEquals/notDeepEquals expect type T for the input parameter. They should actually expect anything except for T, and thus throw a TypeScript error when used correctly in a TypeScript environment.
The simple solution is just to do a generic like such:
but this technique would be overly restrictive for notEquals and I'm unsure how to make it less restrictive without built-in language support. It would additionally require extra boilerplate to handle primitive types, which it currently fails on.
If #47 moves forward then notDeepEquals doesn't need special handling anyway and the simple generic solution proposed above might be the most straightforward fix.
The text was updated successfully, but these errors were encountered:
Honestly, just changing the expected value's type from T to unknown for all equality operators would be better.
Note that, if/when you do that, you'll need a private fake field hack to ensure the type gets passed through for o(1).throws("error") to get correctly rejected.
// Do not exportdeclareconstwrapped: unique symbolnamespaceo{// ...interfaceAssertion<T>{// Set to a function to preserve the correct variance for assignability[wrapped]: (value: T)=>any// Existing methods...}}
Currently,
notEquals
/notDeepEquals
expect typeT
for the input parameter. They should actually expect anything except forT
, and thus throw a TypeScript error when used correctly in a TypeScript environment.The simple solution is just to do a generic like such:
We can also explicitly exclude
T
somehow like such:soulofmischief/DefinitelyTyped@d0268d6
but this technique would be overly restrictive for
notEquals
and I'm unsure how to make it less restrictive without built-in language support. It would additionally require extra boilerplate to handle primitive types, which it currently fails on.If #47 moves forward then
notDeepEquals
doesn't need special handling anyway and the simple generic solution proposed above might be the most straightforward fix.The text was updated successfully, but these errors were encountered: