1

I have been trying to document and set up a type definition for an API that I have to work with and discovered the ability to set a function as a property in the interface. While researching the correct way to do this, I came across this article by Jeff Butsch that states,

Example 1: Function that does not take arguments and does not return a value: In the example belowonChange is the function declaration. The function returns nothing (void) so we declare the return type as any. This is because void and never are evaluated differently in different contexts (beyond the scope of this article). (Below are some examples of typed return values.)

interface MyClassProps {
    someProp: string;
    onChange(): any; } class MyClass extends React.Component<MyClassProps, MyClassState> ...

I have not been able to locate any other references to how Typescript would handle void in a method declaration in a way that would produce unexpected results and make it worth declaring any instead. (Searches for things like 'typescript interface method declaration void any never' return a lot of irrelevant results as those keywords appear with each other in a wide variety of contexts.)

Can anyone offer any insight as to the actual difference here? What problems could potentially be encountered from declaring a method in an interface as returning void when one legitimately expects it to return void?

coppereyecat
  • 161
  • 2
  • 13
  • 3
    If the return type is `any` then a caller can use the return value in completely unsafe ways with no compiler errors (like `myClassProps.onChange().toUpperCase()`). If the return type is `void` then someone who calls the function cannot use the return value at all without error, except for possibly assigning it to a value of type `void`. The return type `void` means "don't try to use the return value from this function". I honestly couldn't say why the article author prefers the unsafe version, and the fact that it's "beyond the scope of this article" doesn't give much to go on. – jcalz Jul 02 '21 at 18:19
  • That was my understanding of it, I was mainly wondering if there actually was a good reason for using `any` when you really mean `void` specifically inside an `interface` declaration. – coppereyecat Jul 02 '21 at 18:23
  • 1
    There are definitely some "weird" behaviors with `void` (see [here](https://stackoverflow.com/questions/65721318/why-is-return-type-null-or-any-other-type-assignable-to-return-type-void) for example) but I wouldn't know why someone would prefer to use `any`, which is arguably "weirder" since it turns off all type checking. So, uh, how could this question get an authoritative answer? I don't know "why one might want to incorrectly declare `any`" other than baseless speculation, which isn't generally appropriate in an SO answer. – jcalz Jul 02 '21 at 18:26
  • It could receive an authoritative answer if someone has a good explanation for what problems the blogger, or a programmer in general, might anticipate by assigning `void` in an interface method. I read it as also having something to do with evaluation of `never` but I might have read that wrong. I'll clarify my wording on the final question. – coppereyecat Jul 02 '21 at 18:53
  • 3
    Does [this question](https://stackoverflow.com/questions/66190346/difference-between-unknown-and-void) shed any light on that? It talks about `unknown` instead of `any`, which is at least a *safe* alternative to `void`. – jcalz Jul 02 '21 at 18:58
  • I didn't know about `unknown` so that was interesting. Still hasn't offered any explanation of a negative side effect that could make someone want to avoid listing a return type as `void`. Maybe the blog I read to begin with was simply incorrect. – coppereyecat Jul 02 '21 at 20:26
  • 1
    You may read a pretty argumented critique of using the `void` type here [microsoft/TypeScript/issues/42709](https://github.com/microsoft/TypeScript/issues/42709). But that's really advanced usage and still doesn't justify using `any` over it. – aleksxor Jul 03 '21 at 20:55

0 Answers0