TypeScript 6.0 RC(devblogs.microsoft.com) |
TypeScript 6.0 RC(devblogs.microsoft.com) |
I would still have a full head of hair if this had been the case since the beginning. Nonetheless I am glad that we got here in the end.
type Dog = { bark: () => void }
type Cat = { meow: () => void }
function speak(animal: Dog | Cat) {
if (‘bark’ in animal) {
animal.bark();
} else {
animal.meow();
}Okay, okay, I know you can filter using ‘in’ to see if it has methods, but in real life, in a company where you have a colleague (who is a golden boy) who writes over-engineered code with hundreds of interfaces of interfaces, you don’t want to spend time searching through the files to find every element that is in the union type.
Whereas in Rust it does:
struct Dog { name: String, }
struct Cat { name: String, }
enum Animal {
Dog(Dog),
Cat(Cat),
fn process_animal(animal: Animal) {
match animal {
Animal::Dog(dog) => {
println!(‘It is a dog named {}’, dog.name);
}
Animal::Cat(cat) => {
println!(‘It is a cat named {}’, cat.name);
}
}I think TypeScript should add a couple of lines of code to the generated JavaScript to do something like:
type Dog = { bark: () => void }
type Cat = { meow: () => void }
function speak(animal: Dog | Cat) {
if (animal is Dog) {
animal.bark();
} else {
animal.meow();
}
} type Dog = { bark(): void; type: 'dog' }
type Cat = { meow(): void; type: 'cat' }
function speak(animal: Dog | Cat) {
if (animal.type === 'dog') {
animal.bark()
} else {
animal.meow()
}
}
TypeScript checks your use of JavaScript runtime features.
[1] https://www.convex.dev/typescript/advanced/type-operators-ma...
https://www.typescriptlang.org/play/?#code/C4TwDgpgBAIg9gcyg...
I thought the answer was 'instanceof'?
https://www.typescriptlang.org/docs/handbook/2/narrowing.htm...
Then: isDog(animal) ? animal.bark() : animal.meow() You get full type narrowing inside conditionals using typeguards.
As a sibling said, discriminated unions are they way to go here. You can also add custom type guard functions if you can't control the objects but you want to centralize the detection of the types, but it's better to let TypeScript do it itself so that you don't mess something up with a cast.
const CatDog = { bark(){}, meow(){} }
const TreeCat = { bark: "oak", meow(){} }
To make types discriminatable you need either
type A = { bark: fn, meow?: never } | { bark?: never, meow: fn }
type B = { species: "dog", bark: fn } | { species: "cat", meow: fn }
or use instanceof with a classThough TypeScript 7.0 will be significant in that it will use the new Go compiler
> TypeScript 6.0 arrives as a significant transition release, designed to prepare developers for TypeScript 7.0, the upcoming native port of the TypeScript compiler. While TypeScript 6.0 maintains full compatibility with your existing TypeScript knowledge and continues to be API compatible with TypeScript 5.9, this release introduces a number of breaking changes and deprecations that reflect the evolving JavaScript ecosystem and set the stage for TypeScript 7.0.
Surely any new feature that causes code to fail to type check when it previously would pass (or vice versa) would have to be considered a breaking change.
A similar thing applies to code formatting tools like Prettier, or any linter.
Yes, typescript would be at version 60 now. No, that's not a problem at all. Numbers are free.
On the other hand, I can understand leaving it as the last thing to do, after the foundation has set. Also, the TypeScript team has really done an amazing job all these years with backward compatibility, so that is extremely reassuring.
Maybe my uneasiness is just impatience to get to use the sped-up version in my app as well! :)
The moduleResolution: node deprecation is the one I'd flag for anyone not paying attention yet. Switching to nodenext forced us to add .js extensions to all
relative imports, which was a bigger migration than expected.
Compilation speed improvement is real though. Noticeably faster on incremental builds.I think the last estimate I saw was the the Go port compiled to WASM was going to be about triple the size of the minified JS bundle.
Now when .NET team complains about adoption I get to point out Typescript 7's contribution repo.
And yes I know the reasons, my nick is on the discussions, please also watch the BUILD session where they acknowledge having to rewrite the whole datastructures due to Go's weaker type system.
It would have been an affront to have a 6.0 that shipped without the means to work for so so many javascript frameworks/libraries. AlCalzone utterly saving the day.
I also am so so so thankful that maybe perhaps after what felt like a never ending dolldrums, we may finally be getting decorator support in some browsers. What a colossal relief it will be to see the progress of the language become manifest.
TypeScript allows entirely LLM-coded PRs?
For example, it wasn't until Typescript 2.0 that we got null checks!
- https://www.typescriptlang.org/docs/handbook/release-notes/t...
function getLength(s: string): number {
return s.length; // Runtime crash if s is null/undefined
}
getLength(null); // TypeScript <2.0 would not error here
You can't do `instanceof Dog`. `instanceof` is a JavaScript feature
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Someone please tell the LLM naming committee.
const imposter: Mutt = { bark: () => console.log("woof"), meow: () => console.log("meow"), }
You're both misunderstanding parent's point as well as the original point. Nobody ever claimed your link wouldn't compile.
Well imo GP is fundamentally misunderstanding TypeScript. It's explicitly a structural language not a nominal one. It goes against the entire design philosophy of TS
But instead your rebuttal was pointing out that TypeScript can compile OP's example code, which OP presented as valid TypeScript that they disliked. I'm not defending their position, I'm just saying that it didn't appear you had even properly read their comment.