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

Always document Any? #12428

Closed
srittau opened this issue Jul 25, 2024 · 1 comment · Fixed by #12430
Closed

Always document Any? #12428

srittau opened this issue Jul 25, 2024 · 1 comment · Fixed by #12430
Labels
project: policy Organization of the typeshed project

Comments

@srittau
Copy link
Collaborator

srittau commented Jul 25, 2024

I'd like to propose a policy that we require any use of un-aliased Any to be accompanied by a comment described why the Any is needed. Using Any is always a bit of a red flag to me (although of course often needed), and it's often not overly obvious why Any is required. We've started to tackle this problem in the past by adding few aliases to better document the use of Any, which was a great start. But sometimes it's also not clear whether Any is really required or whether it's just a placeholder. And that situation also changes over time as the type system gains new features.

Of course, this only applies to new or changed annotations. I don't propose that we need to go through all existing Anys.

@srittau srittau added the project: policy Organization of the typeshed project label Jul 25, 2024
srittau added a commit to srittau/typeshed that referenced this issue Jul 25, 2024
@Avasam
Copy link
Collaborator

Avasam commented Jul 25, 2024

Obligatory xref #9550 ^^ whilst

I don't propose that we need to go through all existing Anys.

it still prevents regressing

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
project: policy Organization of the typeshed project
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants