3 ms·

I’m not sure anybody has ever convinced me that unknown is meaningfully better than any, in any scenario (pun). I get that it’s “typesafe” on the surface but we

I’m not sure anybody has ever convinced me that unknown is meaningfully better than any, in any scenario (pun). I get that it’s “typesafe” on the surface but we both know you’re going to turn around and cast it to the type you think it is so what’s the point

moritzwarhier 4y ago
Using type predicates. But yes that can be tedious.
jeroenhd 4y ago
It depends on your setup. I've worked with a tslint setup that treats `any` as an error, only accepting `unknown` (or in bad situations, `never`) for stuff like Javascript code. If you treat `unknown` as C's `void*`, then you're not getting much out of your type checks.
cypress66 4y ago
Probably to make you parse it with a schema validation library, which will throw if it fails to do so.
anderskaseorg 4y ago
You can safely cast an `unknown` to a desired type with a runtime check from a library like Zod (https://zod.dev/ https://zod.dev/). The `unknown` makes sure you don’t forget a check.
bluepnume 4y ago
In that case what's the point of any type system at all? Any type can be cast to another. If you don't just arbitrarily cast whenever you like, unknown is extremely useful to remind you to type check or parse before you use a value.
johtso 4y ago
No, I'm going to parse it with zod and make sure it is what I think it is.
jcparkyn 4y ago
One advantage is that unknown makes it clear at a glance where the unsafe cast is happening, and forces devs to do it in a reasonable place (rather than letting `any` propagate through the code accidentally). Personally though, I think vscode should have a feature to automatically highlight `any` variables is TS code, which would serve roughly the same purpose. As another commenter mentioned, this is much better when using something like Zod to do the cast safely.
phpnode 4y ago
`any` is infectious, a blackhole for type safety. You can accidentally pass values with `any` all over the place and TS won't complain, but it also won't catch any mistakes you make. `unknown` is much more restrictive and you can't accidentally pass those values around without refining the type, it's much safer.
forrest2 4y ago
If you have tight interfaces that fully encapsulate the use of any, you're fine. If you want to return `any` or pass it around outside of an insulated zone, you're gonna have a bad time. `any` is a contagious/viral construct where anything it touches could become `any`. And then you spiral out of control and the whole codebase gets nothing from typescript but gets all the operational overhead. If your browser doesn't support text fragments, can cmd/ctrl+f for "contagious" and/or "gradual" https://www.typescriptlang.org/docs/handbook/typescript-in-5-minutes-func.html#:~:text=contagious https://www.typescriptlang.org/docs/handbook/typescript-in-5...... Final note is that you likely shouldn't blindly cast unknown to stuff that you hope it is but instead use type guards to find out what the type is. Zod is really good at making this ergonomic for most use cases. More niche types using nonprimitives or uncopyable attributes require hand rolled type guards :/ Type guards also update the type of your unknown var after it passes through them if you gate scopes with them if(isX(y)) {...} Additional guards will merge attributes onto the type

moritzwarhier 4y ago

Using type predicates. But yes that can be tedious.

jeroenhd 4y ago

It depends on your setup. I've worked with a tslint setup that treats `any` as an error, only accepting `unknown` (or in bad situations, `never`) for stuff like Javascript code. If you treat `unknown` as C's `void*`, then you're not getting much out of your type checks.

cypress66 4y ago

Probably to make you parse it with a schema validation library, which will throw if it fails to do so.

anderskaseorg 4y ago

You can safely cast an `unknown` to a desired type with a runtime check from a library like Zod (https://zod.dev/ https://zod.dev/). The `unknown` makes sure you don’t forget a check.

bluepnume 4y ago

In that case what's the point of any type system at all? Any type can be cast to another. If you don't just arbitrarily cast whenever you like, unknown is extremely useful to remind you to type check or parse before you use a value.

johtso 4y ago

No, I'm going to parse it with zod and make sure it is what I think it is.

jcparkyn 4y ago

One advantage is that unknown makes it clear at a glance where the unsafe cast is happening, and forces devs to do it in a reasonable place (rather than letting `any` propagate through the code accidentally). Personally though, I think vscode should have a feature to automatically highlight `any` variables is TS code, which would serve roughly the same purpose. As another commenter mentioned, this is much better when using something like Zod to do the cast safely.

phpnode 4y ago

`any` is infectious, a blackhole for type safety. You can accidentally pass values with `any` all over the place and TS won't complain, but it also won't catch any mistakes you make. `unknown` is much more restrictive and you can't accidentally pass those values around without refining the type, it's much safer.

forrest2 4y ago

If you have tight interfaces that fully encapsulate the use of any, you're fine. If you want to return `any` or pass it around outside of an insulated zone, you're gonna have a bad time. `any` is a contagious/viral construct where anything it touches could become `any`. And then you spiral out of control and the whole codebase gets nothing from typescript but gets all the operational overhead. If your browser doesn't support text fragments, can cmd/ctrl+f for "contagious" and/or "gradual" https://www.typescriptlang.org/docs/handbook/typescript-in-5-minutes-func.html#:~:text=contagious https://www.typescriptlang.org/docs/handbook/typescript-in-5...... Final note is that you likely shouldn't blindly cast unknown to stuff that you hope it is but instead use type guards to find out what the type is. Zod is really good at making this ergonomic for most use cases. More niche types using nonprimitives or uncopyable attributes require hand rolled type guards :/ Type guards also update the type of your unknown var after it passes through them if you gate scopes with them if(isX(y)) {...} Additional guards will merge attributes onto the type