Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: Support unknown, rename TypeId::ANY_TYPE -> TypeId::UNKNOWN_TYPE #137

Open
CharlesTaylor7 opened this issue Apr 19, 2024 · 1 comment
Labels
checking Issues around checking enhancement New feature or request

Comments

@CharlesTaylor7
Copy link
Contributor

Right now unknown isn't supported:

If I try to check

function returnsUnknown(): unknown {
    return 2;
}

I get Cannot find type unknown.


Based on the Ezno announcement post, I'm understanding that Ezno wants to treat the any type the same as the tsc unknown type. i.e. a type with no information or constraints on it.

From the Ezno announcement post

TypeScript has a bit of a funky implementation around any allowing a to be cast as a string in the above example. Implementing any this way makes TypeScript easier to adopt and allows things to compile in weird environments. However for Ezno to do its optimisations this magic any type that has the property of all types without narrowing doesn’t quite work.

Since codebases will undoubtedly have an amalgam of both any, and unknown types sprinkled through out; I'm proposing a few things

  • Both any and unknown get supported by mapping them to the same internal type.
  • Rename TypeId::ANY_TYPE to TypeId::UNKNOWN_TYPE, because it more closely matches that construct in TSC.
  • I would want both unknown and any to still be shown in error messages as they were written in source code.
@kaleidawave kaleidawave added enhancement New feature or request checking Issues around checking labels Apr 19, 2024
@kaleidawave
Copy link
Owner

Yep, similar to never I don't think unknown has been wired up to point to at a type. I don't know much about how unknown works and when to use it in TypeScript.

I do think the two types need to exist separately though. If you want printing to be different between them they can't have the same TypeId. Maybe when I do get around to it I should create impl TypeId { fn is_inferred_constaint(&self) -> bool { self == TypeId::UNKNOWN_TYPE || self == TypeId::ANY_TYPE } } to make sure they are considered the same.

This will be a part of #35 which I got working a while ago but removed as I wanted to change the implementation. Hoping to have another look it when I have more time next month as I want some inference stuff in the next release!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
checking Issues around checking enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants