Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TypeScript 6.0 RC

devblogs.microsoft.com

Post reply on HN
Print view View original

41–50 of 52 posts

Re: TypeScript 6.0 RC

#41

Post by culi »

reitzensteinm wrote: post #36
culi wrote: post #32

Earlier quoted context omitted.

Try it https://www.typescriptlang.org/play/?#code/C4TwDgpgBAIg9gcyg...

type Mutt = Dog & Cat 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.

I see what you mean, thanks

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

Re: TypeScript 6.0 RC

#42

Post by culi »

Incipient wrote: post #40
culi wrote: post #26

Earlier quoted context omitted.

Your first code block works exactly as you would expect and has been working like that for many years https://www.typescriptlang.org/play/?#code/C4TwDgpgBAIg9gcyg...

The op did say they didn't want to do these type of checks. I thought the answer was 'instanceof'? https://www.typescriptlang.org/docs/handbook/2/narrowing.htm...

I see what you mean, thanks. instanceof works if you're using javascript classes but not for "types".

You can't do `instanceof Dog`. `instanceof` is a JavaScript feature

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Re: TypeScript 6.0 RC

#43

Post by reitzensteinm »

culi wrote: post #41
reitzensteinm wrote: post #36

Earlier quoted context omitted.

type Mutt = Dog & Cat 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.

I see what you mean, thanks 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

It would have been a super reasonable reply to talk about the history of TypeScript, why fundamentally its types exist to retroactively describe complicated datastructures encountered in real world JavaScript. And why when TypeScript overstepped that by creating enums, which require code generation and not mere type erasure to compile, it was decided to be a mistake that they won't repeat.

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.

Re: TypeScript 6.0 RC

#44

Post by JoeyJoJoJr »

culi wrote: post #27
littlecranky67 wrote: post #22

Earlier quoted context omitted.

Typeguard is what you are looking for: function isDog(animal: Dog | Cat): animal is Dog { return "bark" in Dog } Then: isDog(animal) ? animal.bark() : animal.meow() You get full type narrowing inside conditionals using typeguards.

You don't even need that. The code exactly as presented acts as a discriminator. TypeScript is smart enough to handle that logic in the if block and know whether animal has been validated as Dog vs Cat. GP is complaining about a feature that already exists in TypeScript

I’m not at my computer so I can’t remember the exact behavior of this situation, but was OP more so referring to autocomplete abilities of typescript? I think they were saying, you first must know if the object barks or meows, you must first type that in in order to get the benefit of type checking and subsequent autocomplete conditional body, which is annoying when you are dealing with complicated types. It requires you to do some hunting in to the types, rather than using a piece of code more like an interface.

Re: TypeScript 6.0 RC

#45

Post by pjmlp »

I would rather have seen C# Native AOT for the Typescript 7, alongside Blazor for the playground, but it is what is.

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.

Re: TypeScript 6.0 RC

#46

Post by lenkite »

pjmlp wrote: post #45

I would rather have seen C# Native AOT for the Typescript 7, alongside Blazor for the playground, but it is what is. 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.

Yeah, its strange that Microsoft is not dogfooding its own stuff. Even as an "enterprise" Go developer myself, I would have preferred that Typescript was written in C# - it keeps language ecosystems diverse. And ensures that C# continues to improve.

Re: TypeScript 6.0 RC

#47

Post by ivanjermakov »

mdtrooper wrote: post #12

What has always bothered me about TypeScript are union types. If you have a function that receives a parameter such as ‘Dog | Cat’, you cannot separate it. For example: 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 l…

That's intentional, TS types are erased in runtime. My go-to way for this is discriminated unions: https://www.typescriptlang.org/docs/handbook/unions-and-inte...

Re: TypeScript 6.0 RC

#48

Post by dimava »

mdtrooper wrote: post #12

What has always bothered me about TypeScript are union types. If you have a function that receives a parameter such as ‘Dog | Cat’, you cannot separate it. For example: 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 l…

And then you have a

    const CatDog = { bark(){}, meow(){} }
and

    const TreeCat = { bark: "oak", meow(){} }
and your code stops working

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 class

Re: TypeScript 6.0 RC

#49

Post by karmakaze »

mdtrooper wrote: post #12

What has always bothered me about TypeScript are union types. If you have a function that receives a parameter such as ‘Dog | Cat’, you cannot separate it. For example: 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 l…

What always bothers me with enums, sealed-types, etc is that I can't compose a new ad-hoc set based on elements of someone else's enum. You can make one using the other but not the other way around, TypeScript's is more general.

Re: TypeScript 6.0 RC

#50

Post by paulddraper »

Analemma_ wrote: post #11
alembic_fumes wrote: post #5

> strict is now true by default 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.

TypeScript never would’ve taken off if it had been strict from the beginning, it would’ve been just another forgotten gravestone next to Dart and CoffeeScript. I’m not saying those are bad languages, they’re not, but anything other than a very slow and gradual opt-in transition was just a non-starter. It was painful, but TypeScript played the long game.

Many of the strict checks did not even exist when TS was first created.
Post reply on HN