-
Notifications
You must be signed in to change notification settings - Fork 12.4k
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
Disallow assigning void
to unknown
#50752
Comments
See also #42709. Possibly a duplicate but maybe not; the |
@fatcerberus I don't think #42709 suggests this, does it? In any case, it seems to be more ambitious and I'm not sure if I agree with all suggestions made. |
Oh definitely, #42709 is way more ambitious.
Which argues to your point, that |
@fatcerberus Ah, I see your point. I thought that this was the official/intended purpose of |
Wait, the StackOverflow answer I mentioned is by Ryan, who is the dev lead, so I guess that does make it the official purpose. |
Yep, To be 100% clear, I agree with your suggestion -
The official docs could definitely use some fleshing out, IMO. |
Plenty of information got lost as part of v2 of the handbook as well. The old handbook writes about
Emphasis mine. Can be misunderstood as well, but I always understood "The absence of any type" as "do not attempt to use this value, it could be anything". |
This seems like a good idea, any reasons why this suggestion could cause problems? Decreasing developer errors is always welcome in my books. |
This is actually not doable; many things would break. If // Implicit constraint of F is 'unknown'
type ReturnType<F> = F extends (() => infer U) ? U : "no";
// Correct type of S is "no", instead of void (today)
type S = ReturnType<() => void>; So that means that we'd have to change the implicit constraint of all generic types to The example in the OP is, to me, completely uncompelling. print(foo.getLength); // forgot to call the function! |
Ah okay, thanks for the explanation. That's unfortunate, so I guess we don't really have a type that means "anything that you're meant to look at", only "anything and maybe you're not supposed to look at this". In my head |
Suggestion
π Search Terms
β Viability Checklist
My suggestion meets these guidelines:
I think this would be acceptable, but if not, a compiler flag could be added so it does not break existing code.
β Suggestion
Disallow the assignment of
void
expressions tounknown
type.void
means a value is not supposed to be used, and assigning it to anunknown
variable/parameter contradicts this.This is like #45750 but with
unknown
instead ofany
. I think this proposal may have a higher chance to be accepted sinceany
is sort-of meant to accept any value, however absurd, and e.g. some people may define callback functions as() => any
, which would then have the unintended effect of blocking passing() => void
.π Motivating Example
Also see #45750, but the DOM lib currently uses
any
a lot, so it won't have as much effect there yet.π» Use Cases
Prevent usage of a value which was not meant to be used.
E.g. prevent bugs with passing a void result to logging or serializing functions.
I think this would also help mitigate #18433.
The text was updated successfully, but these errors were encountered: