4 ms·

That's absolutely bonkers. What's the use case here? Also does that mean the following: console.log(person.spells); // <-- compilation error if (!isWizard(

That's absolutely bonkers. What's the use case here? Also does that mean the following: console.log(person.spells); // <-- compilation error if (!isWizard(person)) { return[]; } return person.spells; // <-- this is fine

deleted 8y ago
[deleted]
barrkel 8y ago
The use case is having types depend on control flow so that guarded control flow paths don't need further typecasting. I don't see how this is bonkers. It looks like a great ergonomic feature to me. As to your code, sure, it's an error. But it's not unusual, conceptually. For example: if (foo) { int bar = 22; } print(bar); // compilation error?? And this: if (foo) { print(bar); // compilation error?? int bar = 22; } More idiomatically, you'd expect to read code like this: if (isWizard(person)) { person.wizardStuff(); } I think this is not an unusual thing to do in dynamically typed languages, especially when interfacing with third-party code where you can't easily add new polymorphic methods (so you can't rely on virtual dispatch to handle your if-case logic). Making it work more ergonomically in typescript isn't "absolutely bonkers".
adrusi 8y ago
Typescripts goal is to allow using existing JavaScript idioms while gaining the advantages of static type checking. I don't think it's too bonkers for the type of a variable to change within the same scope, as long as there's some clear delineation. In rust you can redeclare a variable with the same name but different type: let x: i32 = 99; println!("{}", x); let x: &str = "shadows"; println!("{}", x); Kotlin does something very similar to typescript for null checks: https://kotlinlang.org/docs/reference/null-safety.html https://kotlinlang.org/docs/reference/null-safety.html I don't know what's so crazy about a variable's type changing within the same scope except that languages from before 2010 mostly didn't allow that.
- steveklabnik 8y ago
  To be clear, this doesn’t change the type in Rust. It creates a new variable with the same name. Very different thing!

deleted 8y ago

[deleted]

barrkel 8y ago

The use case is having types depend on control flow so that guarded control flow paths don't need further typecasting. I don't see how this is bonkers. It looks like a great ergonomic feature to me. As to your code, sure, it's an error. But it's not unusual, conceptually. For example: if (foo) { int bar = 22; } print(bar); // compilation error?? And this: if (foo) { print(bar); // compilation error?? int bar = 22; } More idiomatically, you'd expect to read code like this: if (isWizard(person)) { person.wizardStuff(); } I think this is not an unusual thing to do in dynamically typed languages, especially when interfacing with third-party code where you can't easily add new polymorphic methods (so you can't rely on virtual dispatch to handle your if-case logic). Making it work more ergonomically in typescript isn't "absolutely bonkers".

adrusi 8y ago

Typescripts goal is to allow using existing JavaScript idioms while gaining the advantages of static type checking. I don't think it's too bonkers for the type of a variable to change within the same scope, as long as there's some clear delineation. In rust you can redeclare a variable with the same name but different type: let x: i32 = 99; println!("{}", x); let x: &str = "shadows"; println!("{}", x); Kotlin does something very similar to typescript for null checks: https://kotlinlang.org/docs/reference/null-safety.html https://kotlinlang.org/docs/reference/null-safety.html I don't know what's so crazy about a variable's type changing within the same scope except that languages from before 2010 mostly didn't allow that.

steveklabnik 8y ago
To be clear, this doesn’t change the type in Rust. It creates a new variable with the same name. Very different thing!