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

I very much hope that ts will provide any as an implicit type, thank you #60536

Open
6 tasks done
1057105012 opened this issue Nov 19, 2024 · 2 comments
Open
6 tasks done
Labels
Unactionable There isn't something we can do with this issue

Comments

@1057105012
Copy link

1057105012 commented Nov 19, 2024

🔍 Search Terms

When writing ts, sometimes the type must be given, such as lambda. If you don’t want to write it, you must also give it: any. One is fine, but if there are many, the mental burden is very heavy

I want any to be the default type. If the function parameter type, function return value type, and variable type are not specified, the default type will be automatically deduced to any instead of reporting an error.

For asynchronous functions, the return value is allowed to be declared as a basic type and automatically inferred as a Promise, and defaults are also allowed.

The main purpose is to natively support js syntax in ts. Make ts an add-on rather than a coercion

----- Other suggestions ------
The second problem is that the official documentation of typescript is best to set all the type gymnastics as advanced tutorials and the basic type system as basic tutorials. For most scenarios, we only need type inference of ts, and do not need so many type gymnastics. Moreover, some type gymnastics can be realized through some basic type combinations. this will be complicated

✅ Viability Checklist

⭐ Suggestion

📃 Motivating Example

💻 Use Cases

  1. What do you want to use this for?
  2. What shortcomings exist with current approaches?
  3. What workarounds are you using in the meantime?
@jcalz
Copy link
Contributor

jcalz commented Nov 19, 2024

You didn't fill out the full template.

This already happens if you disable --noImplicitAny, right? Does that not suffice?

@nmain
Copy link

nmain commented Nov 19, 2024

It's hard to say because you didn't provide specific code examples as requested by the issue template, but you might also want noEmitOnError: false.

@RyanCavanaugh RyanCavanaugh added the Unactionable There isn't something we can do with this issue label Nov 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Unactionable There isn't something we can do with this issue
Projects
None yet
Development

No branches or pull requests

4 participants