3 ms·

TypeScript has its own WATs too, and to me they are almost worse, because you have this false sense of security based on it being TypeScript and not JavaScript.

TypeScript has its own WATs too, and to me they are almost worse, because you have this false sense of security based on it being TypeScript and not JavaScript. https://www.typescriptlang.org/play?#code/MYewdgziA2CmB00QHMAUBtARARgAyYBoACHfY0zAXXgFsBDAB1QboCcJYBJMAFwEo+AKCA https://www.typescriptlang.org/play?#code/MYewdgziA2CmB00QHM...

try_the_bass 4y ago
I don't understand why this is a "wat"? This is just a) not understanding how `map` works, and b) not understanding the args to `parseInt`. The callback function for `map` is passed three args: the current item, the index of that item, and the whole array. `parseInt` takes two args[1]: `number` and `radix`. So you're calling (unrolled): parseInt("10", 0) => 10 parseInt("10", 1) => NaN parseInt("10", 2) => 2 This doesn't seem particularly surprising to me? [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/parseInt https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- jjnoakes 4y ago
  Map passes three arguments to parseInt but parseInt only takes two. I think a language with a type system ought to have a way to get a warning for that kind of thing. Especially when it does so in other contexts. I understand why it is this way, but I think it is very surprising and unintuitive behavior.
- jjnoakes 4y ago
  For example (continuing my sibling comment), if you unroll it properly, you do get TypeScript complaints. parseInt("10", 0, ["10", "10", "10"]) parseInt("10", 1, ["10", "10", "10"]) parseInt("10", 2, ["10", "10", "10"]) https://www.typescriptlang.org/play?#code/ATAOEMCcGcFMEkB2AXAFAIgIwAZ0BphsCBtLXAs-YSgXQEoAoECGBFDHKzEyizv3PSZgocJGl7AATD37U5tOkA https://www.typescriptlang.org/play?#code/ATAOEMCcGcFMEkB2AX... So TypeScript intentionally suppresses this kind of complaint when matching up function types even though it issues them when calling functions directly. The reason for that has a justification, but in contexts like this, I think it is a WAT-worthy interaction. https://github.com/microsoft/TypeScript/wiki/FAQ#why-are-functions-with-fewer-parameters-assignable-to-functions-that-take-more-parameters https://github.com/microsoft/TypeScript/wiki/FAQ#why-are-fun...
eyelidlessness 4y ago
That’s a JS WAT, and it’s fair to say TS should error, but TS is explicitly not a linter and the code is “correct” so it’s unclear what else it should do.
- jjnoakes 4y ago
  I disagree that the code is "correct". TypeScript warns for passing too many arguments to functions in other contexts even though that could also be called "correct" because even though it works, it was probably unintentional.
afraca 4y ago
I agree with my sibling comments, but want to add that nowhere does TS imply it has it's own stdlib or anything. If you type map, you know fully it's the JS map that's going to be executed. I don't think TS ever wants or could replace the JS stdlib.

try_the_bass 4y ago

I don't understand why this is a "wat"? This is just a) not understanding how `map` works, and b) not understanding the args to `parseInt`. The callback function for `map` is passed three args: the current item, the index of that item, and the whole array. `parseInt` takes two args[1]: `number` and `radix`. So you're calling (unrolled): parseInt("10", 0) => 10 parseInt("10", 1) => NaN parseInt("10", 2) => 2 This doesn't seem particularly surprising to me? [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/parseInt https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

jjnoakes 4y ago
Map passes three arguments to parseInt but parseInt only takes two. I think a language with a type system ought to have a way to get a warning for that kind of thing. Especially when it does so in other contexts. I understand why it is this way, but I think it is very surprising and unintuitive behavior.
jjnoakes 4y ago
For example (continuing my sibling comment), if you unroll it properly, you do get TypeScript complaints. parseInt("10", 0, ["10", "10", "10"]) parseInt("10", 1, ["10", "10", "10"]) parseInt("10", 2, ["10", "10", "10"]) https://www.typescriptlang.org/play?#code/ATAOEMCcGcFMEkB2AXAFAIgIwAZ0BphsCBtLXAs-YSgXQEoAoECGBFDHKzEyizv3PSZgocJGl7AATD37U5tOkA https://www.typescriptlang.org/play?#code/ATAOEMCcGcFMEkB2AX... So TypeScript intentionally suppresses this kind of complaint when matching up function types even though it issues them when calling functions directly. The reason for that has a justification, but in contexts like this, I think it is a WAT-worthy interaction. https://github.com/microsoft/TypeScript/wiki/FAQ#why-are-functions-with-fewer-parameters-assignable-to-functions-that-take-more-parameters https://github.com/microsoft/TypeScript/wiki/FAQ#why-are-fun...

eyelidlessness 4y ago

That’s a JS WAT, and it’s fair to say TS should error, but TS is explicitly not a linter and the code is “correct” so it’s unclear what else it should do.

jjnoakes 4y ago
I disagree that the code is "correct". TypeScript warns for passing too many arguments to functions in other contexts even though that could also be called "correct" because even though it works, it was probably unintentional.

afraca 4y ago

I agree with my sibling comments, but want to add that nowhere does TS imply it has it's own stdlib or anything. If you type map, you know fully it's the JS map that's going to be executed. I don't think TS ever wants or could replace the JS stdlib.