RS.CLIPPY.REF_OPTION

Function signature uses `&Option<T>` instead of `Option<&T>`

This checker is a Clippy lint created by The Rust Project Contributors. The documentation shown here is a copy of the original documentation for: ref_option. Copyright ©2025 The Rust Team. All rights reserved.

What it does

Warns when a function signature uses &Option<T> instead of Option<&T>.

Why is this bad?

More flexibility, better memory optimization, and more idiomatic Rust code.

&Option<T> in a function signature breaks encapsulation because the caller must own T and move it into an Option to call with it. When returned, the owner must internally store it as Option<T> in order to return it. At a lower level, &Option<T> points to memory with the presence bit flag plus the T value, whereas Option<&T> is usually optimized to a single pointer, so it may be more optimal.

See this YouTube video by Logan Smith for an in-depth explanation of why this is important.

Known problems

This lint recommends changing the function signatures, but it cannot automatically change the function calls or the function implementations.

Example

// caller uses  foo(&opt)
fn foo(a: &Option<String>) {}
fn bar(&self) -> &Option<String> { &None }

Use instead:

// caller should use  `foo1(opt.as_ref())`
fn foo1(a: Option<&String>) {}
// better yet, use string slice  `foo2(opt.as_deref())`
fn foo2(a: Option<&str>) {}
fn bar(&self) -> Option<&String> { None }

Configuration

avoid-breaking-exported-api: Suppress lints whenever the suggested change would cause breakage for other crates.

(default: true)