3 ms·

I'm interested to know what people think about this with TypeScript - quite a lot of the weird behaviour in plain JS is rejected by the compiler, eg, "true == 1

I'm interested to know what people think about this with TypeScript - quite a lot of the weird behaviour in plain JS is rejected by the compiler, eg, "true == 1" evaluates to true in plain JS, but is a compiler error in TypeScript since it rejects bool vs number equality checks. So with TypeScript code, I've been continuing to use == as in most other languages, with the expectation that any odd comparisons will be flagged by the compiler. On the other hand, I've not verified myself that it catches them all, so I wonder if anyone has come across other edge cases with this that could cause problems down the line.

slikts 8y ago
The issue there is that TS allows dropping out of the type system with `any`, so it might not actually be checking the types you're comparing, so I'd still use ===.
kbp 8y ago
I prefer it when Typescript tries to provide static type checking for Javascript rather than providing checking for how they wish Javascript was. `(x: number, y: string) => x == y` is an error because 'this condition will always return false'. In what language? There are linter rules for enforcing === over ==; Typescript having incorrect type definitions to try and make sure you only use == like === seems like a really poor solution to that.
- Sacho 8y ago
  Aren't you implicitly assuming that TS's number === JS's Number and TS's string === JS's String? You could say == is extended for TS's types(number/string), but the JS == still exists: x as any == y as any;
  - kbp 8y ago
    I can see what you're saying, but I think that argument would be a lot stronger if == compiled to ===. If you want an operator with ==='s semantics, it's there; providing == and claiming it behaves like === just seems like an opportunity for annoying surprises if something slips through the cracks. Since == doesn't compile to ===, I wouldn't use it unless I understood its semantics and wanted them.
- arisb 8y ago
  I'm guessing you can't use `(x: number, y: string) => x === parseInt(y)`?
  - jaaames 8y ago
    As long as you feed parseInt it's second radix parameter you can :p
  - deleted 8y ago
    [deleted]
deleted 8y ago
[deleted]
deleted 8y ago
[deleted]

slikts 8y ago

The issue there is that TS allows dropping out of the type system with `any`, so it might not actually be checking the types you're comparing, so I'd still use ===.

kbp 8y ago

I prefer it when Typescript tries to provide static type checking for Javascript rather than providing checking for how they wish Javascript was. `(x: number, y: string) => x == y` is an error because 'this condition will always return false'. In what language? There are linter rules for enforcing === over ==; Typescript having incorrect type definitions to try and make sure you only use == like === seems like a really poor solution to that.

Sacho 8y ago
Aren't you implicitly assuming that TS's number === JS's Number and TS's string === JS's String? You could say == is extended for TS's types(number/string), but the JS == still exists: x as any == y as any;
- kbp 8y ago
  I can see what you're saying, but I think that argument would be a lot stronger if == compiled to ===. If you want an operator with ==='s semantics, it's there; providing == and claiming it behaves like === just seems like an opportunity for annoying surprises if something slips through the cracks. Since == doesn't compile to ===, I wouldn't use it unless I understood its semantics and wanted them.
arisb 8y ago
I'm guessing you can't use `(x: number, y: string) => x === parseInt(y)`?
- jaaames 8y ago
  As long as you feed parseInt it's second radix parameter you can :p
- deleted 8y ago
  [deleted]

deleted 8y ago

[deleted]

deleted 8y ago

[deleted]