You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Passing never type as a function parameter does not fail type checkΒ #56952
OK, understood -- but is there a reason it doesn't work a bit more like unknown? Would there be any downside to preventing a never value to be passed around since that seems to indicate an error case, or at least probably not what the code author intended.
I'm not sure what rule you're proposing. At best, you'd introduce many different inconsistencies where higher-order and zero-order forms disagreed about validity.
I'm arguing from a 'principle of least surprise' angle. If I try to pass a never value into a function, and that function doesn't explicitly accept never as a parameter type, there's like a 99% chance I'm doing something I shouldn't be, and a warning would help me fix that mistake.
My proposal is there would be some setting similar to noImplicitAny which makes never unusable. Once I have a never value, I would be unable to return it, pass it to any function, unless those functions explicitly have never types defined as inputs or outputs. Essentially how unknown behaves.
Is there a real world example where someone would actually want to be able to pass or return a never?
never is a subtype of all types while unknown is a supertype of all types. They are different by nature. I don't expect and don't want them to behave the same.
Just recently had someone on the team vibe-coding stuff and casting every variable to never, passing as arguments to functions. Effectively bypassing typecheck and lint (we have linting rules to disallow explicit any).
Activity
RyanCavanaugh commentedon Jan 4, 2024
neveris the empty set; the subtype of all types. By definition, it is assignable to anything.bluepnume commentedon Jan 4, 2024
OK, understood -- but is there a reason it doesn't work a bit more like
unknown? Would there be any downside to preventing anevervalue to be passed around since that seems to indicate an error case, or at least probably not what the code author intended.RyanCavanaugh commentedon Jan 4, 2024
I'm not sure what rule you're proposing. At best, you'd introduce many different inconsistencies where higher-order and zero-order forms disagreed about validity.
bluepnume commentedon Jan 4, 2024
I'm arguing from a 'principle of least surprise' angle. If I try to pass a
nevervalue into a function, and that function doesn't explicitly acceptneveras a parameter type, there's like a 99% chance I'm doing something I shouldn't be, and a warning would help me fix that mistake.My proposal is there would be some setting similar to
noImplicitAnywhich makesneverunusable. Once I have anevervalue, I would be unable to return it, pass it to any function, unless those functions explicitly havenevertypes defined as inputs or outputs. Essentially howunknownbehaves.Is there a real world example where someone would actually want to be able to pass or return a never?
RyanCavanaugh commentedon Jan 4, 2024
Sure, you might have something like this
MichalMarsalek commentedon Jan 5, 2024
neveris a subtype of all types whileunknownis a supertype of all types. They are different by nature. I don't expect and don't want them to behave the same.typescript-bot commentedon Jan 8, 2024
This issue has been marked as "Working as Intended" and has seen no recent activity. It has been automatically closed for house-keeping purposes.
ianldgs commentedon Jul 1, 2025
Just recently had someone on the team vibe-coding stuff and casting every variable to
never, passing as arguments to functions. Effectively bypassing typecheck and lint (we have linting rules to disallow explicitany).