Rust does a lot of smart things to determine the types of variables. This is why you rarely need to define the types of a variable explicitly. Rust can search very far to find a type for a function. For example, this is invalid:

let i;

but this is valid:

let i;

These lines do not need to be next to eachother. There can be a lot of code in between.


Consider this rust answer:


This won't compile. You need to specify the type for a and b. To make this compile you would need


However, often rust answers have test cases, so the full code will look more like this:

fn main(){
f = 

asserteq!(f(1,2), 1);

This compiles, the test case in this case tells rust the type of the function, even though it appears much later in the code.

Many answers use this trick so save bytes, for example:

Not criticizing any of these answers, there where all valid when posted.

There might also be cases when the test cases accidentally limit the return type too, or the type of a global variable. Just listing those for argument types since the issue is easier to spot but it's not the only way the type can be defined outside the block itself.


Should it be allowed for the types of arguments in rust (and maybe other languages that have implicit static typing) be allowed to derive from test cases?

  • \$\begingroup\$ Related issue in C# with no clear consensus: codegolf.meta.stackexchange.com/q/10974/91213 \$\endgroup\$
    – mousetail
    Commented Sep 28, 2022 at 9:16
  • \$\begingroup\$ As someone who's responsible for a fair number of these answers, the standard I've used is "can coerce into an appropriately typed function pointer", mainly to avoid cluttering up the test cases with type annotations. I've upvoted Bubbler's answer because it's mostly equivalent and more in line with site precedent. \$\endgroup\$
    – Aiden4
    Commented Sep 30, 2022 at 1:25
  • 3
    \$\begingroup\$ Haskell already does this. \$\endgroup\$
    – naffetS
    Commented Oct 2, 2022 at 0:56
  • 1
    \$\begingroup\$ I think this question is answered in codegolf.meta.stackexchange.com/questions/11223/… \$\endgroup\$
    – corvus_192
    Commented Oct 16, 2022 at 9:41

2 Answers 2


If Rust's type inference can infer argument types using external information, it is OK to omit them

There is a precedent for Haskell allowing this.

But note that Rust's type inference is a lot weaker than e.g. Haskell's. If you omit types when Rust can't infer them even with context, your answer is invalid, and should be fixed to include the types so that the code compiles.

  • \$\begingroup\$ +1 Husk, too, does this all the time. In fact, if I'm not mistaken, the parsing of a Husk program can be affected by what argument types are passed to it. \$\endgroup\$
    – DLosc
    Commented Oct 1, 2022 at 0:14
  • \$\begingroup\$ Arguably that's not just a precedent in Haskell. That question uses Haskell as an example but it asks in general and the top voted answer makes no mention of a specific language. \$\endgroup\$
    – Wheat Wizard Mod
    Commented Oct 3, 2022 at 13:55

Implicit parameter types should be allowed

We write code to be used. If the compiler can implicitly infer the types by calling the function the exact same way you would with explicit parameter types, and with the exact same output, it should be allowed.


Not the answer you're looking for? Browse other questions tagged .