-
Notifications
You must be signed in to change notification settings - Fork 12.5k
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
Revisit void/unknown/undefined interactions #52486
Comments
Related: #42709 |
I think this is a duplicate of #42709 (if it's not, a compare/contrast is necessary) Re this error: function foo(): undefined {} I agree it's silly. I think we would take a PR that allows no return statements in a function returning exactly |
Updates from the team chat:
|
Allowing implicit returns when implicit returns are explicitly disallowed feels really weird. |
@MartinJohns with |
It's all pretty ironic since, for all the holes our type system has, knowing that a function with no return statements will return |
I always figured it was intentional: if you annotate as |
Fixed by #53092 |
Current situation
void
is a special type which behaves likeunknown
with three exceptions (that I am aware of):undefined
.void === undefined
for the purposes of narrowing. In other words, this type-checks whereunknown
would not:void
may have non-returning code branches.Problems
Firstly, I am aware that the unsoundness caused by these special cases is intentional: that in itself is not the issue I am raising. The issue is that with other unsoundness, you can usually opt-in to more sound type-checking. For example, with
any
, users have the option to not use it - instead usingunknown
or generics to get a more sound (if more verbose) solution.With
void
, we have no choice. There is no way to say that a function returnsundefined
, because the following does not type-check:This stems from the fact that
void
servese two purposes:There are additional problems with
void
when it comes to async functions. SincePromise<void>
is not compatible withPromise<undefined>
it works against itself, resulting in spurious type errors where there should be none.Suggestion
undefined
.undefined
instead ofvoid
for functions which do not return a value.Not all code paths return a value.
warning to fire only when some but not all codepaths have an explicit return.Of these (1) is not a breaking change. (2) may cause some breakage if the return-type of such a function is extracted via
ReturnType<F>
. (3) would cause warnings for functions which use a mix of implicit/explicit returns.For this reason, it may be desirable to implement these changes behind a new configuration option.
Overall this would improve typescript because it allows more valid code to compile, while providing more sound type-checking. Common errors like accidentally ommitting a
return
statement will still be caught. The language will be simpler to learn becausevoid
and its special rules will be encountered less often. These changes could be the start of a gradual phase-out of thevoid
type entirely in favour ofunknown
.🔍 Search Terms
void undefined unknown explicit implicit return function unsound soundness
✅ Viability Checklist
My suggestion meets these guidelines:
The text was updated successfully, but these errors were encountered: