Repository navigation
Consider making implicit any the default for all generic type parameters #13609
Description
Now that we have generic defaults (:tada:), we should consider making all type parameters have an implicit any default. An unspecified uninferred type parameter would have type any and trigger a warning under noImplicitAny.
Benefits:
- We'll need to do this in Salsa anyway
- Improves JS migration story for codebases which inherit from generic base classes
Drawbacks:
- There may exist people who run with
noImplicitAnyoff but still want to enforce type parameters to be provided?
Activity
falsandtru commentedon Jan 22, 2017
It's a really great improvement.
I definitely want it.
RyanCavanaugh commentedon Jan 24, 2017
Ron Buckton (@rbuckton) interested in folding this into your current PR? We can also do it later instead
mhegazy commentedon Jan 24, 2017
I would keep this in a separate PR.
gcnew commentedon Jan 24, 2017
Wouldn't this be at odds with #1213 and #9949?
DanielRosenwasser commentedon Jan 24, 2017
Marin Marinov (@gcnew) could you elaborate on that thought?
gcnew commentedon Jan 24, 2017
My hunch is that defaulting parameters to an implicit value is not a good idea in general. I don't have anything specific, it was more like throwing in areas where potential issues may reside.
Giving it a second thought, defaulting parameters to
anywill make the checker more permissive for users withnoImplicitAnyoff. If #1213 and #9949 get implemented, the checker will become more restrictive again, which may be viewed as a backwards compatibility problem. On the other hand this proposal is beneficial fornoImplicitAnyusers.DanielRosenwasser commentedon Jan 24, 2017
Marin Marinov (@gcnew) I don't think that the implicit
{}constraint type is much better though. If anything,{}is confusing for newcomers, and the behavior of getting it rather thananyis actually more confusing for those who are familiar withnoImplicitAny. I do think that the positives you listed are pretty compelling though, and explain much of the rationale for this proposal.Ryan Cavanaugh (@RyanCavanaugh) I just want to clarify the intent - is it all type parameters including those which have explicit defaults?
RyanCavanaugh commentedon Jan 24, 2017
If there's an explicit default, we would obviously use that instead of
any. Maybe I don't understand the question.DanielRosenwasser commentedon Jan 24, 2017
Sorry, I meant to ask about explicit constraints, not explicit defaults.
RyanCavanaugh commentedon Mar 22, 2017
Somehow decided we should do #10571 as part of this discussion