Should We Have a Rule for Variable Type Annotation?

[pellico]

This issue tracks the discussion related to type annotation in variable declarations for the Rust coding guidelines project.

The main question is:

Is it possible to misunderstand code (e.g., during code review) if the type is not explicit and we rely solely on type inference?

Note: This issue is not about ambiguity in type detection by the compiler.

Summary of Discussion

Arguments in Favor of a Coding Guideline

Here are some arguments for and against type inference. For more context checkout meeting minutes 20-10-2025

Advocacy for More Type Declarations

In VSCode, rust-analyzer adds type declarations when they are missing. This suggests that deducing the type of a variable is not always trivial and that explicit types can improve code understanding.
Relying on rust-analyzer and VSCode introduces a safety dependency on these tools. (What happens if they display incorrect information?)
rust. rust-analyzer can show very complex types because it look through typedef Type annotations "look through" typedefs, which can be confusing.

A blog proposing restrictions on the use of auto in C++

Advocacy for Fewer Type Declarations

Some C++ blogs recommend minimizing explicit type declarations:

Type deduction and the auto keyword are powerful tools in modern C++ that greatly simplify coding, help the readability of the code, and improve maintainability. By allowing the compiler to infer types, these features reduce boilerplate code and minimize errors. From simplifying complex type declarations to facilitating code refactoring, type deduction and auto are indispensable in contemporary C++ programming. Embracing these tools can lead to cleaner, more efficient, and more readable code, ultimately making C++ development a more streamlined and enjoyable process.

Exploring C++ Type Deduction and auto Keyword

Arguments Against a Coding Guideline

MISRA C++ does not have a rule regarding the use of auto in variable declarations.

There are no known examples where missing type declarations have led to dangerous misunderstandings during code review.

TL;DR

• Do you think it is necessary to have a rule about type inference in Rust?
• If yes, do you have an example where a missing type declaration led to a bug being missed during code review?

[senier]

• Do you think it is necessary to have a rule about type inference in Rust?

I'm still not sure. I asked around and discussed this a bit and the closest we could come up with is:

struct Foo;

impl Foo {
    fn my_method(&self) {
        println!("Inherent!");
    }
}

trait MyTrait {
    fn my_method(&self);
}

impl MyTrait for Foo {
    fn my_method(&self) {
        println!("Trait!");
    }
}

fn main() {
    let f = Foo;
    // Inherent!
    f.my_method();
    // Trait!
    MyTrait::my_method(&f);
}

But that's not really a variable type annotation... I'm leaning towards not needing such a rule.

[felix91gr]

For the general case of type annotations, I don't currently have a strong opinion on whether or not they should be encouraged or not. They do help me read code, but that's a sample of just 1 that I have - my own experience doesn't necessarily reflect others' experiences.

That being said: for whenever one is working in unsafe, in particular:

• When one is working with conversion into or from raw pointers, as well as
• When one is working with transmute,

I would argue that being 100% explicit using type annotations is extremely helpful here. And given the unsafe nature of these kinds of conversions, I would make it mandatory to add type annotations to those operations.

Transmutation, for example, looks like this with type annotations: transmute::<T, U>(x), meaning "Reinterpret x, which is of type T, as a variable of type U with the exact same bytes as x".